Feedback-ID: ia2694551:Fastmail
Date: Thu, 20 Mar 2025 18:48:27 +0100
From: =?utf-8?Q?=C3=81lvaro?= Herrera <alvherre@alvh.no-ip.org>
To: "David G. Johnston" <david.g.johnston@gmail.com>
Cc: Sebastien Flaesch <sebastien.flaesch@4js.com>, 
	Tom Lane <tgl@sss.pgh.pa.us>, Adrian Klaver <adrian.klaver@aklaver.com>, 
	M Tarkeshwar Rao <m.tarkeshwar.rao@ericsson.com>, "pgsql-general@postgresql.org" <pgsql-general@postgresql.org>
Subject: Re: After upgrading libpq, the same function(PQftype) call returns a
 different OID
Message-ID: <202503201748.wxkazqupyvuk@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAKFQuwZHL1eATNRMBDszHwQ+jGdp5A92dQxMDi2gBdHf-eG__Q@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/202503201748.wxkazqupyvuk%40alvherre.pgsql>
Precedence: bulk

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