Hi,
On 16.01.22 16:18, Julien Rouhaud wrote:
> Hi,
> On Sun, Jan 16, 2022 at 04:06:45PM +0100, Mario Emmenlauer wrote:
>> Actually I do not really mean to include `postgres.h`. But I do want
>> to identify result types with `Oid vOID = ::PQftype(mResult.get(), vColumn);`
>> to check the result type. And the types seem to be defined in header
>> `catalog/pg_type.h` which only worked when `postgres.h` was included before.
>>
>> I guess I'm off the standard track here. Its not completely mandatory for
>> me to identify the result types. But it was quite nice to be able to do
>> so.
>>
>> Is this actually unsupported? Or am I doing something wrong?
>
> It's supported and multiple clien-side programs access those constants.
> However you don't need to include postgres.h for that. There are examples in
> the tree that relies on OID defines if you want to check how it's done, for
> instance src/bin/pg_dump/pg_dump.c.
>
> Note that the OIDs aren't in pg_type.h anymore since pg 11. Are you still
> compiling against pg 10 or less?
Ah, this is very helpful! Indeed I developed this code against pg 9.x!
I can see the OID's now in `catalog/pg_type_d.h` and I found a related
commit that may be just exactly what you refer to:
9c0a0de4c9 Tom Lane Switch client-side code to include catalog/pg_foo_d.h not pg_foo.h.
So I assume `catalog/pg_type_d.h` is really what I want! And it does not
need `postgres.h`. Thanks!
All the best,
Mario
