On Fri, Oct 14, 2022 at 4:35 PM Tom Lane <tgl@xxxxxxxxxxxxx> wrote: > > I don't. I used > > https://github.com/postgres/postgres/blob/master/src/include/catalog/pg_type.dat > > They're stable Good to know, thanks. > but writing magic numbers leads to unreadable code. > Use the macros from catalog/pg_type_d.h. OK. I see that header. But it seems to be a "server" header, not a client one. I.e. I'm not sure it's a good idea to depend on such a header for pure client-side libpq code. > >> For types from an extensions, you would run a query on "pg_type". > > OK, thanks. > > In SQL queries, you can avoid hard-wiring anything by writing > things like "'hstore'::regtype". It may or may not be possible > to avoid fetching the OID altogether that way. Something like below you mean? Thanks for the tip. I do need to OIDs, on binds and results (defines in OCI speak), in my C++ code. Because I try to enforce strong type safety between the C++ world, and the libpq "bytes". I don't check OIDs of the values on binds, I just give them to libpq on execute(). But for results, I compare the actual OID (from PGresult) and the expected OID from the C++ type (via the traits). ddevienne=> select 'hstore'::regtype; regtype --------- hstore (1 row) ddevienne=> select 'hstore'::regtype::oid; oid ----------- 207025799 (1 row) ddevienne=> select 'uuid'::regtype::oid; oid ------ 2950 (1 row) ddevienne=> select 'uuid[]'::regtype::oid; oid ------ 2951 (1 row)
