On Fri, Oct 14, 2022 at 4:35 PM Tom Lane <tgl@sss.pgh.pa.us> 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)