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
