Peter Eisentraut <peter_e@gmx.net> writes:
> What would be the best way to digest the output of libpq's PQftype()?
> (Perhaps a char * PQftypetext() would be of general use?)
> (The issue here is that I do _not_ want to have to query pg_type for that
> information, since psql has no business contacting the database server
> when not asked to do so.)
You can't have it both ways: either you look up the OID in pg_type,
or the info you provide is incomplete/unreliable.
For the standard system types like int4, text, etc, it's probably OK
for client code to assume that particular numeric OIDs correspond to
those types --- use the #defines that are in catalog/pg_type.h, such as
BOOLOID, to refer to those types. (I think there are one or two places
in libpq and/or psql that do this already, eg, to decide whether a
column is "numeric".) The backend does this all over the place, but
it's a little shakier for frontend code to do it, because a frontend
might possibly be used with other database versions than the one it was
compiled for. Still, I think you could get away with it for standard
types --- AFAIK no one has any intention of renumbering those.
(Thomas has been muttering dire things about the date/time types, so
you might be well advised not to assume anything about those ;-).)
It would not be an unreasonable idea for libpq to provide a general
purpose type-OID-to-type-name mapper, with the understanding that this
mapper *would* query the backend at need. (Of course it should know
automatically about the most common standard types, and it should cache
the results of previous lookups so any one OID is queried at most once
per connection.) We have heard from a number of people who have built
exactly that facility for their applications, so it's obviously useful.
regards, tom lane