Feature Request: Adding Meta Data to Results

[JensRavens]

I really like the work you've been doing on this project, as this seems to be the easiest to use Postgres library for Swift so far that also works beautifully on my iOS app.
Now to my request: I'm currently trying to build a new app that would allow the user to type in SQL queries himself on a custom database (so I don't know the schema upfront). The user can use that feature to generate custom reports, charts, ..., and there needs to be a way of naming things and do some introspection of query results.

I do agree with your FAQ saying that one shouldn't use name based indices to retrieve values, but would it be possible to somehow retrieve the name of a column and it's type?

Think about a query like this (that the user will input into a text field of the running app):

SELECT count(*) AS population, born_at
FROM people
GROUP BY born_at

I would like to display the label population in the graph, effectively giving the user the possibility to steer everything about the graph/report with SQL (also finding out that born_at is a date, and therefore correctly displaying it in the UI).

Any hints or directions on this?

[pitfield]

This is similar to #12.

This information is available from the server. Currently PostgresClientKit doesn't ask for it, for the reasons outlined in the FAQ. Also, fetching this data requires an extra server request & response.

As an enhancement, PostgresClientKit could allow the caller to indicate they wish this metadata, and only perform the extra request in that case.

[pitfield]

Some of this metadata is also available in the information_schema, which could be queried without enhancement to PostgresClientKit. But this would require at least partially parsing the SELECT statement (for example, to extract the table name).

[JensRavens]

Thank you for the response. Parsing it is quite hard (just thinking of cross table joins, functions and all the fancy stuff a user could potentially do to create a select statement). I changed the app architecture now to require a server side component that does the processing and then publishes the content via graphQL. It's a step back in my opinion as I would have liked to keep the app server free, but it works.

[pitfield]

Re-opening because it would be a nice enhancement to implement someday.

[niklassaers]

Thanks for making PostgresClientKit. Really useful. :-) I'd like to throw my +1 in here, at least for column names. I get that this would be an extra request, and if that's a problem then perhaps I could specify wanting to get metadata back in the statement?

[pitfield]

Added a new parameter, retrieveColumnMetadata, to Statement.execute(...), defaulting to false. If true, result metadata is retrieved and can be accessed through the new columns property of Cursor. The result metadata includes the name and data type of each column in the results (plus some other stuff).

[pitfield]

Available in v1.2.0.