Re: After upgrading libpq, the same function(PQftype) call returns a different OID

"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> On Thu, Mar 20, 2025 at 11:54 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I think it's a mistake to suppose that pg_type_d.h is the only
>> place where there's a risk of confusion. We should be thinking
>> about this more generally: genbki.pl is taking zero thought to
>> make what it emits readable. I think it would help to
>> label the sections it emits, perhaps along the lines of
>> /* Auto-generated OID macros */

> I'd consider this enough for the moment, so long as we explicitly address
> the cross-version constancy of the OID values associated with each type.

That's documented elsewhere, I believe. For the foo_d.h files,
I think it'd be sufficient to do something like 0001 attached.

Also, while checking out the results, I noticed that pg_class.h
has an "extern" in the wrong place: it's exposed to client code
which can have no use for it. That extern doesn't mention any
backend-only typedefs, so it's fairly harmless, but it's still
a clear example of somebody not reading the memo. Hence 0002.

> I'm not going to dive deep enough to make more targeted suggestions. It
> does seem, though, that "client code" would seem mostly interested in these
> OIDs and not stuff like the attribute numbers of the columns in pg_type. I
> get a distinct feel of one file serving multiple use cases.

Well, yes it does, but that doesn't make those symbols useless to
client code.

regards, tom lane