Include column type in CLI query output

[big-andy-coates]

When outputting the results of a query (push & pull) in the CLI, it would be nice to include the SQL type of the column, e.g. STRING, INT, etc and the namespace of the column, e.g. KEY or META.

So rather than seeing:

+------------------------------------------------+------------------------------------------------+
|ROWKEY                                          |COUNT                                           |
+------------------------------------------------+------------------------------------------------+
|ITEM_1                                          |1                                               |
Query terminated

The user would see something like:

+------------------------------------------------+-----------------------------------------------+
|ROWKEY STRING KEY                               |COUNT BIGINT                                   |
+------------------------------------------------+-----------------------------------------------+
|ITEM_1                                          |1                                              |
Query terminated

[agavra]

I felt like we had a discussion somewhere but I can't seem to find record - the conclusion was not to add these. Basically, it adds bloat to the column headers and you can usually tell what the type is from looking at the column value. Further, none of the other databases do this (not postgres or MySQL at least) as far as I can tell.

Personally, I don't care much one way or another, but I just wanted to point that out.

cc @rmoff might have some opinions

[rmoff]

@agavra are you thinking of this? #3526
In that issue I advocate (and still do) that the REST API should return this kind of information in a parseable way.

I concur with your view that in the CLI itself it's not a standard thing to expect.

For me the difference between the two is that

• the CLI is for human consumption and seeing a data type in the column heading is not something I would expect to see and as you say isn't standard elsewhere AFAIK
• the REST API is for integration and the schema metadata is useful to expose for this reason