Feature request: access field names and types even when NO rows are returned - #209
Conversation
|
I like this idea. Do you think you could write a simple failing test w/ the api you imagined? Usually helps me get a head start on new features. Doing this in javascript will be trivial. The trickier part will be having the native driver do the same thing, but should be doable. |
|
I was about to look into this when I found a "rowDescription" event |
|
Actually, since we're at it, it would be also good to get field types too ! |
|
@brianc: check out |
|
awesome - just saw this update. will check this out asap - been a crazy past week |
|
this is a pretty beefy change, but I like it. Will work on this when I get a bit more time. Just giving it a little bump. 💡 |
|
👍 This change would make it possible to actually write a generic frontend for Postgres using Node.js, similar to phpPGAdmin. The same API presented in that failing test can actually be used in conjunction with the |
|
Any news on this ? |
|
On accessing field names when no rows are returned? |
|
both field names and field types |
|
Cant be more supportive of the idea. Needed for lot of instrospection |
|
k - working on it now |
|
@brian let me know when this is ready for test, or if you need help, thank you |
|
@strk thanks! I got held up this weekend with a bunch of family coming in to town. This is next on my list for this week. ❤️ |
|
@brianc any progress here ? |
|
Ok, I'm giving this a try, within today I should have a pull request ready. |
|
In order to fix the test I produced earlier we should maintain a mapping between oid and type names as type names are not in the protocol (only oid). But now I'm not sure it is ok to maintain such mapping internally. The mapping could be different across different databases (especially for custom types). Maybe the library could expose a function to update the typeName database and provide a basic one... |
|
or (cleaner) we just pass over the type oid and let the calling code do whatever they want with it |
|
For some background info, my development database has ~750 types. Note that any table also becomes a type. |
Adds a 'rowDescription' event in query object. Add test for accessing field info via both event and result object
|
Just passing the type's OID back to the user would work fine, as long as we provided a way to look up the type name that corresponds to a given OID... basically, provide lazily-loaded/cached type information whenever the user requests it. Another possibility would be to provide an option which would cause node-postgres to automatically look up type names for any type OIDs it encounters in query results that it doesn't already have cached, but only if the user requests it. (since in the case of a cache miss, that would incur an extra query's worth of overhead, we wouldn't want that to be default behavior) |
|
The cleanest way would be to just return oid and let caller do any lookup/caching... |
|
Yeah returning just the OID is the way to go. There's a query which can be run to pull the mapping from type to name out of the database if a client is interested. I'll push it when it's finished. |
Closes #209 Native implementation requires significant refactor and so I wont work on this if/until there is an issue for it
|
@strk this should solve your issue, yes? |
|
Yes, I think that's good. |
|
💃 yay! merging & pushing new version now |
Feature request: access field names and types even when NO rows are returned
4 participants
A common trick to get information about the structure of a query result is to run the query with a LIMIT 0 thus only getting the field names and types.
This trick seems to be impossible to do with the node-postgresql module because the only place where field names are available is within a result row, so no rows means no such info.
I hope I'm missing something. If not, this would be a really useful addition.
I've been thinking the information could be passed as part of the .end() event, with information being filed names and data types.