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

On Thu, Mar 20, 2025 at 8:42 AM Sebastien Flaesch <sebastien(dot)flaesch(at)4js(dot)com>
wrote:

>
> */**
> * * Backwards compatibility for ancient random spellings of pg_type OID
> macros.*
> * * Don't use these names in new code.*
> * */*
> #define CASHOID MONEYOID
> #define LSNOID PG_LSNOID
>
> #define BOOLOID 16
> #define BYTEAOID 17
> #define CHAROID 18
> #define NAMEOID 19
> #define INT8OID 20
> #define INT2OID 21
> #define INT2VECTOROID 22
> #define INT4OID 23
> #define REGPROCOID 24
>
> If I am missing something, then please point me to the correct .h file
> that contains #define constants without this scary comment.
>
> OR.... ( I guess I start to understand the code... ) it this comment only
> for:
>

Yes, that blank line separating LSNOID and BOOLOID blocks the comment from
applying to the items after the blank line. That is a fairly common
convention, using whitespace to break things up. Also, assigning one macro
to another is quite distinct from assigning a constant to a name; making
the "backward compatibility" aspect of this comment only meaningfully apply
to those two items.

> And sorry if I consider constant names like these (without any prefix such
> as PG_TYPE_)
>

We spelled PG_TYPE_ as OID and put it on the end. A boolean as an object
is by definition a type. Context clues are important, not every pattern
gets spelled out in prose.

> #define BOOLOID 16
> #define BYTEAOID 17
> #define CHAROID 18
> #define NAMEOID 19
> #define INT8OID 20
> #define INT2OID 21
>
> Arrogance does not help here, clarity and better API doc would.
>
>
To my knowledge the current API doc for this hasn't had any comments of
this sort for a very long time. All documentation can be improved because
every reader comes at it from a different starting point. Do you have a
concrete suggestion for what you think should be changed, and why? My take
away from this thread is that a single report isn't usually enough to go
searching hard for ways to tweak the documentation for readability; nor has
this one pointed out any outright errors to be fixed. In short, we expect
that some subset of readers will ask us questions on the mailing list
because that is the reality of things.

That said, I am curious as to the education flow a developer, not linking
in this specific header to their code, would go through in order to learn
about type OIDs and make use of them in their project. Maybe that flow is
good, maybe not. It's a rare flow and there are many things to do in the
project. So my curiosity may not get satiated. As you brought this up and
are invested in the outcome you have more motivation than probably anyone
else to dive into it and make concrete suggestions for change.

All that said, a comment at the top of what is probably the most important
section of the header seems warranted. Even if it is just mostly
formality. Mentioning the constant-ness of the integers should be part of
that.

David J.