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
