[Feat] Add v.db.columns to get columns for vector map

[wenzeslaus]

Is your feature request related to a problem?

There is several tools which can give your columns of a table associated connected to a layer in a vector map. Neither is particularly great.

Both v.info and v.db.connect seem to support column info as an afterthought: You need to use a flag which completely changes what is printed and in both cases, instead of operating on the whole vector map, the tools starts to operate on a specific layer (table connection) only.

While db.columns is meant to give columns of a table (unlike the other tools), it operates on tables directly, not on vector maps, so while basic case happens to work, more complex cases require explicit handling of database connection details. (See also #6072 for discussion on what db.columns should print besides the column names.)

v.db.select is doing selects on the data, but it can be "misused" as a metadata getter tool.

Describe the solution you'd like

I would like to have a specific tool, v.db.columns, which is meant from the start to provide users with information about columns. This tool would be the clear, primary way of obtaining column names and whatever information we provide. We already have multiple ways, 3 or 4 depending on what you count. Having another will not make the situation worse. Having a tool which is actually meant to do it, as opposed to doing it as a secondary feature, should clarify the overall interface.

In addition to that, the two series of database-related tools, v.db and db might be confusing, but one way to reduce the potential confusion is to have corresponding tools in both categories, for example, we have v.db.univar and db.univar. We have db.columns. We should also have v.db.columns.

Describe alternatives you've considered

Alternative is using one of the four existing ways.

Additional context

We already started to discuss this in #6072 with @HuidaeCho but since then I realized we have also v.db.connect -c duplicating the output of v.info -c in the same way of "let's completely change what this tool does". This indicates that a dedicated tool, aligned with db.columns, is needed.

Examples with the current tools

v.info:

$ grass ~/grassdata/nc_spm_08_grass7/PERMANENT/ --exec v.info map=geology -c
INTEGER|cat
DOUBLE PRECISION|onemap_pro
DOUBLE PRECISION|PERIMETER
INTEGER|GEOL250_
INTEGER|GEOL250_ID
CHARACTER|GEO_NAME
DOUBLE PRECISION|SHAPE_area
DOUBLE PRECISION|SHAPE_len

v.db.connect:

$ grass ~/grassdata/nc_spm_08_grass7/PERMANENT/ --exec v.db.connect map=geology -c
INTEGER|cat
DOUBLE PRECISION|onemap_pro
DOUBLE PRECISION|PERIMETER
INTEGER|GEOL250_
INTEGER|GEOL250_ID
CHARACTER|GEO_NAME
DOUBLE PRECISION|SHAPE_area
DOUBLE PRECISION|SHAPE_len

db.columns:

$ grass ~/grassdata/nc_spm_08_grass7/PERMANENT/ --exec db.columns table=geology
cat
onemap_pro
PERIMETER
GEOL250_
GEOL250_ID
GEO_NAME
SHAPE_area
SHAPE_len

v.db.select:

$ grass ~/grassdata/nc_spm_08_grass7/PERMANENT/ --exec v.db.select map=geology where=false format=json | jq '.info.columns'
[
  {
    "name": "cat",
    "sql_type": "INTEGER",
    "is_number": true
  },
...

[petrasovaa]

The question is how this should be implemented, a wrapper around one of the other tools?