db.columns: added support for -e to print more column information

[gulshan-123]

Towards #6072

Added a new flag -e, which will show more information about the column names, similar to v.info
The flag is supported for both plain and json format.

NOTE for reviewer: I have created a new if else condition based on -e flag, thus the older code for handling without -e flag is indented and is shown as red in the git diff.
But all the previous code is present. Thanks.

GRASS nc_spm_08_grass7/PERMANENT:grass > db.columns geology -e format=json
[
    {
        "name": "cat",
        "sql_type": "INTEGER",
        "is_number": true
    },
    {
        "name": "onemap_pro",
        "sql_type": "DOUBLE PRECISION",
        "is_number": true
    },
    {
        "name": "PERIMETER",
        "sql_type": "DOUBLE PRECISION",
        "is_number": true
    },
    {
        "name": "GEOL250_",
        "sql_type": "INTEGER",
        "is_number": true
    },
    {
        "name": "GEOL250_ID",
        "sql_type": "INTEGER",
        "is_number": true
    },
    {
        "name": "GEO_NAME",
        "sql_type": "CHARACTER",
        "is_number": false
    },
    {
        "name": "SHAPE_area",
        "sql_type": "DOUBLE PRECISION",
        "is_number": true
    },
    {
        "name": "SHAPE_len",
        "sql_type": "DOUBLE PRECISION",
        "is_number": true
    }
]
GRASS nc_spm_08_grass7/PERMANENT:grass > db.columns geology -e format=plain
cat: INTEGER
onemap_pro: DOUBLE PRECISION
PERIMETER: DOUBLE PRECISION
GEOL250_: INTEGER
GEOL250_ID: INTEGER
GEO_NAME: CHARACTER
SHAPE_area: DOUBLE PRECISION
SHAPE_len: DOUBLE PRECISION

[petrasovaa]

Looks like the compilation fails:

2026-01-23T03:17:07.6778460Z main.c: In function 'parse_command_line':
2026-01-23T03:17:07.6791105Z main.c:195:21: error: assignment to 'int *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
2026-01-23T03:17:07.6794824Z   195 |     parms.more_info = more_info->answer ? TRUE : FALSE;
2026-01-23T03:17:07.6796796Z       |                     ^
2026-01-23T03:17:07.6916454Z make[4]: *** [../../include/Make/Compile.make:32: OBJ.x86_64-w64-mingw32/main.o] Error 1
2026-01-23T03:17:07.6917603Z make[4]: Leaving directory '/d/a/grass/grass/db/db.columns'

[gulshan-123]

Thank you for the review. I have taken all the suggestions. Also, I have added one test each for json and plain with -e flag.

Also, one question:
I have downloaded nc_spm_08_grass7 from the grass website but it does not contain zipcode table, which is used in the current file testsuite. Instead it contains zipcodes_wake which I believe is same as zipcode? So, I have used zipcodes_wake to run the testsuite locally. Am I correct?

~/grassdata/nc_spm_08_grass7/PERMANENT/vector$ ls
boundary_county  busroutesall        elev_lid792_randpts    geology        P079214               railroads      swwake_10m
boundary_municp  busstopsall         elev_lidrural_mrpts    geonames_NC    P079215               roadsmajor     urbanarea
bridges          censusblk_swwake    elev_lidrural_mrptsft  geonames_wake  P079218               schools_wake   usgsgages
busroute1        census_wake2000     elev_ned10m_cont10m    hospitals      P079219               soils_general  zipcodes_wake
busroute11       comm_colleges       firestations           lakes          poi_names_wake        soils_wake
busroute6        elev_lid792_bepts   geodetic_pts           nc_state       precip_30ynormals     streams
busroute_a       elev_lid792_cont1m  geodetic_swwake_pts    overpasses     precip_30ynormals_3d  streets_wake

[nilason]

Thank you for the review. I have taken all the suggestions. Also, I have added one test each for json and plain with -e flag.

Also, one question: I have downloaded nc_spm_08_grass7 from the grass website but it does not contain zipcode table, which is used in the current file testsuite. Instead it contains zipcodes_wake which I believe is same as zipcode? So, I have used zipcodes_wake to run the testsuite locally. Am I correct?

~/grassdata/nc_spm_08_grass7/PERMANENT/vector$ ls
boundary_county  busroutesall        elev_lid792_randpts    geology        P079214               railroads      swwake_10m
boundary_municp  busstopsall         elev_lidrural_mrpts    geonames_NC    P079215               roadsmajor     urbanarea
bridges          censusblk_swwake    elev_lidrural_mrptsft  geonames_wake  P079218               schools_wake   usgsgages
busroute1        census_wake2000     elev_ned10m_cont10m    hospitals      P079219               soils_general  zipcodes_wake
busroute11       comm_colleges       firestations           lakes          poi_names_wake        soils_wake
busroute6        elev_lid792_bepts   geodetic_pts           nc_state       precip_30ynormals     streams
busroute_a       elev_lid792_cont1m  geodetic_swwake_pts    overpasses     precip_30ynormals_3d  streets_wake

The test data currently used is:
https://grass.osgeo.org/sampledata/north_carolina/nc_spm_full_v2beta1.tar.gz

[petrasovaa]

One last thing, please add an example of the -e flag and json in the documentation (just the md file is enough). You can shorten the json output if it gets too long. Thank you!

[gulshan-123]

Without -e flag, the json format was already shown in the python example, so I have skipped adding them.
I have added shell commands and their outputs with -e flag for both plain and json format.

Here is the docs rendering for format=json:

[petrasovaa]

Thank you!

[gulshan-123]

There seems to some maybe unrelated Linting error?

Also, I am going ahead to add format=csv and format=list in db.columns as suggested in this comment of original issue: #6072 (comment)

I think specifying option separator should be in both list and csv format, but not in json and plain format.

In list: (TYPE will be printed only in case of -e): default separator=newline

name1 TYPE1[separator]name2 TYPE2[separator] ..

eg. with sep=new line:

cat INTEGER
onemap_pro DOUBLE PRECISION

In CSV:(if -e is not present, then, only name column will be printed) default separator=comma

name[separator]type[separator]is_number
name1[separator]type1[separator]true/false

eg:

name,type,is_number
cat,INTEGER,true
onemap_pro,DOUBLE PRECISION,true

Is this idea good?

[echoix]

The linting error is fixed on main now

[petrasovaa]

Is this idea good?

Yes, you got it right. The idea with the plain vs list output is that the list output is parsable in command line and the format is part of API, while the plain output could potentially change.