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

On 2025-Mar-20, David G. Johnston wrote:

> 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.

That said, we could add a comment that makes this more obvious:

diff --git a/src/include/catalog/pg_type.h b/src/include/catalog/pg_type.h
index ff666711a54..bce7d8796e2 100644
--- a/src/include/catalog/pg_type.h
+++ b/src/include/catalog/pg_type.h
@@ -341,6 +341,9 @@ MAKE_SYSCACHE(TYPENAMENSP, pg_type_typname_nsp_index, 64);
*/
#define CASHOID MONEYOID
#define LSNOID PG_LSNOID
+/*
+ * End of backwards compatibility section.
+ */

#endif /* EXPOSE_TO_CLIENT_CODE */

This looks a tad redundant in pg_type.h itself, but makes the generated
pg_type_d.h file more obvious:

/*
* 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
/*
* End of backwards compatibility section.
*/

#define BOOLOID 16
#define BYTEAOID 17

--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
"I must say, I am absolutely impressed with what pgsql's implementation of
VALUES allows me to do. It's kind of ridiculous how much "work" goes away in
my code. Too bad I can't do this at work (Oracle 8/9)." (Tom Allison)
http://archives.postgresql.org/pgsql-general/2007-06/msg00016.php