Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tve5I-006hSp-Or for pgsql-general@arkaria.postgresql.org; Fri, 21 Mar 2025 15:14:57 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tve5H-009L30-DC for pgsql-general@arkaria.postgresql.org; Fri, 21 Mar 2025 15:14:55 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tve5G-009L1a-Ud for pgsql-general@lists.postgresql.org; Fri, 21 Mar 2025 15:14:55 +0000 Received: from mail-ot1-x331.google.com ([2607:f8b0:4864:20::331]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tve5F-000KoJ-0b for pgsql-general@postgresql.org; Fri, 21 Mar 2025 15:14:54 +0000 Received: by mail-ot1-x331.google.com with SMTP id 46e09a7af769-728a433ec30so402040a34.1 for ; Fri, 21 Mar 2025 08:14:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1742570092; x=1743174892; darn=postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=hhRkV2e+ZjCRfnaK6i2qTJeb//GL+iG2P+VhnrvUy20=; b=RTk/M8q2dap+hvBVt2MEWLheSu6dcFHZ0fehbKujg/9WeQAWB1itDvgwUk8noeTO8J 5N4ExhbbUD/zw6HP7+h9herQ6FOIfJagiaysVe8qLsC9T1UpyE6KPB+wvGECs3hp1DT5 dPpz+X1AKPRU6oNuyEIuaYbIizOs8s9H+nIcUCAJ3y8YUL7gbsFax43qE3Izq7KMJ3lA 7bIWAUsa6yR0lU0vWwwWyeB8dxvxIXGxqWXVizn6c/o7fO92Y6pOukvl9BDMYfEelQlV 5iUxsc7P4pBehNySawQWGVxCVWK78roJjxOmyutYEZJSaD9ZkcR7FhaB2V1FSzqN4P6l yimg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742570092; x=1743174892; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=hhRkV2e+ZjCRfnaK6i2qTJeb//GL+iG2P+VhnrvUy20=; b=lPs1YqVrGbWQxtQHuxj4CTzPrYTXctaUI26ZTH7SkTrEg+gKyOTJeNK8d6dJxMcx2x dKDiGNUTCOFbqodlCGj7bfWL56EHZUbyfpEk9gfBb91bGJIBvqOmvOUpfdODbPUsT6Ng R4W1Xc7z7bjAOcsj9b/0cMGg06obREt9QtWQQjdeS4pxBYV0C6WdzGUw9mbtoKuHm8WF maPa+AjTBv3W2iQZlGU0e8qQUOWFPmTC6ldyQd8+HvltwA1e2hFdTlUn2MTNybTX6paG a4XKrurHZZlhmM184/NLHkcvsFU8vVz+6Oln/yZv/iHUetp8uu5YBhDMCH6vUFsrAekg z5uQ== X-Forwarded-Encrypted: i=1; AJvYcCXrg8Z7vdF6vUFwnFdzPeu928MEA/C/ZEksDWxhag20mJSWHi67Ar5+xiVZJJN4fHvYcuLx7uJz9xdcvzUp@postgresql.org X-Gm-Message-State: AOJu0YznC7uMimmllfbKp6ag2Mc1msEqEpNyhrMw+hOdItECBYR42BPt BJ27YU0fENxV7dbSzHsdIUppa7zj/QG+sqDta8oZb2mIWDYaZQWJoQ+mlFpxX/5KOlh7xJdw5E/ 0bkS4VinwexJFGtPTV47LeasJqOo= X-Gm-Gg: ASbGncuB5J9bL26S9unT4dFvufSB7ewxAvb3TSp3+IMwFq7bW8ZJbYomonxy84sFbrS Gr6IeVxNpnenHGJ3cDXwkrQ65rAiJVVhyaIKwGO8EtlUuqv/vC+TM8B46IJdbxseD7fC9H1P3n4 +4Tn7bWj2a2i5tRwMnqCKKT0IO X-Google-Smtp-Source: AGHT+IGmPGWqmbTn4O+5ZRkQLxrsWn/raa3CBhU2E46JWwT1ms2oligZVfdWTuFvxv+ldNbUlppL98b2X2IM09JHCvY= X-Received: by 2002:a05:6830:63cc:b0:72b:9965:d994 with SMTP id 46e09a7af769-72c0af1a9dcmr2515620a34.23.1742570092149; Fri, 21 Mar 2025 08:14:52 -0700 (PDT) MIME-Version: 1.0 References: <202503201748.wxkazqupyvuk@alvherre.pgsql> <1092933.1742496844@sss.pgh.pa.us> <1134562.1742507765@sss.pgh.pa.us> In-Reply-To: <1134562.1742507765@sss.pgh.pa.us> From: "David G. Johnston" Date: Fri, 21 Mar 2025 08:14:14 -0700 X-Gm-Features: AQ5f1Jpr3iZRK9bdAkezfGZMOtKP8oOyKSgrlceNv2WxtSnGm_l6xFvrbNV7Ssk Message-ID: Subject: Re: After upgrading libpq, the same function(PQftype) call returns a different OID To: Tom Lane Cc: =?UTF-8?Q?=C3=81lvaro_Herrera?= , Sebastien Flaesch , Adrian Klaver , M Tarkeshwar Rao , "pgsql-general@postgresql.org" Content-Type: multipart/alternative; boundary="00000000000056c6b20630dbb712" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000056c6b20630dbb712 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Mar 20, 2025 at 2:56=E2=80=AFPM Tom Lane wrote: > "David G. Johnston" writes: > > On Thu, Mar 20, 2025 at 11:54=E2=80=AFAM Tom Lane w= rote: > >> I think it's a mistake to suppose that pg_type_d.h is the only > >> place where there's a risk of confusion. We should be thinking > >> about this more generally: genbki.pl is taking zero thought to > >> make what it emits readable. I think it would help to > >> label the sections it emits, perhaps along the lines of > >> /* Auto-generated OID macros */ > > > I'd consider this enough for the moment, so long as we explicitly addre= ss > > the cross-version constancy of the OID values associated with each type= . > > That's documented elsewhere, I believe. For the foo_d.h files, > I think it'd be sufficient to do something like 0001 attached. > > WFM. Thanks. Also, while checking out the results, I noticed that pg_class.h > has an "extern" in the wrong place: it's exposed to client code > which can have no use for it. That extern doesn't mention any > backend-only typedefs, so it's fairly harmless, but it's still > a clear example of somebody not reading the memo. Hence 0002. > > Maybe tack this onto genbki.h? diff --git a/src/include/catalog/genbki.h b/src/include/catalog/genbki.h index 26e205529d..4a1567a46b 100644 --- a/src/include/catalog/genbki.h +++ b/src/include/catalog/genbki.h @@ -146,4 +146,6 @@ */ #undef EXPOSE_TO_CLIENT_CODE +/* Additional backend-only code is placed after the client-code section. *= / + #endif /* GENBKI_H */ David J. --00000000000056c6b20630dbb712 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Mar 20, 2025 at 2:56=E2=80=AFPM Tom Lane <tgl@sss.pgh.pa.us> wrote:
"David G. Johnston" <david.g.johnston@g= mail.com> writes:
> On Thu, Mar 20, 2025 at 11:54=E2=80=AFAM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I think it's a mistake to suppose that pg_type_d.h is the only=
>> place where there's a risk of confusion.=C2=A0 We should be th= inking
>> about this more generally: genbki.pl is taking zero thought to
>> make what it emits readable.=C2=A0 I think it would help to
>> label the sections it emits, perhaps along the lines of
>> /* Auto-generated OID macros */

> I'd consider this enough for the moment, so long as we explicitly = address
> the cross-version constancy of the OID values associated with each typ= e.

That's documented elsewhere, I believe.=C2=A0 For the foo_d.h files, I think it'd be sufficient to do something like 0001 attached.


WFM.=C2=A0 Thanks.

Also, while checking out the results, I noticed that pg_class.h
has an "extern" in the wrong place: it's exposed to client co= de
which can have no use for it.=C2=A0 That extern doesn't mention any
backend-only typedefs, so it's fairly harmless, but it's still
a clear example of somebody not reading the memo.=C2=A0 Hence 0002.

=

Maybe tack this onto genbki.h?

<= /div>
diff --git a/src/include/catalog/genbki.h b/src/include/catalog/gen= bki.h
index 26e205529d..4a1567a46b 100644
--- a/src/include/catalog/g= enbki.h
+++ b/src/include/catalog/genbki.h
@@ -146,4 +146,6 @@
=C2= =A0 */
=C2=A0#undef EXPOSE_TO_CLIENT_CODE
=C2=A0
+/* Additional ba= ckend-only code is placed after the client-code section. */
+
=C2=A0#= endif =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 /* GENBKI_H */

David J.

--00000000000056c6b20630dbb712--