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 1tvMCu-003qYK-Gv for pgsql-general@arkaria.postgresql.org; Thu, 20 Mar 2025 20:09:36 +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 1tvMCs-0086Tx-NV for pgsql-general@arkaria.postgresql.org; Thu, 20 Mar 2025 20:09:34 +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 1tvMCs-0086Sw-8q for pgsql-general@lists.postgresql.org; Thu, 20 Mar 2025 20:09:34 +0000 Received: from mail-oa1-x34.google.com ([2001:4860:4864:20::34]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tvMCp-000Bzt-3D for pgsql-general@postgresql.org; Thu, 20 Mar 2025 20:09:33 +0000 Received: by mail-oa1-x34.google.com with SMTP id 586e51a60fabf-2a9ef75a20dso1363432fac.2 for ; Thu, 20 Mar 2025 13:09:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1742501371; x=1743106171; 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=HHkf0HBgHGIV6HCG7t6tjumqai+IBk2OP83pNwikXNM=; b=J8qcGnvXZeIF6MN4GAoOWfg+DUmosccmEYcWTF13Dy0pBARWFsF1H9lwYU2dMhUsqL yJRsxAIt5943pVelPKyNky4FAQ8MIKOYp0puG32W8FhFJHnekTJzqX6flD0fZLXM5Bat QY7kJXb08RwhgYA1jg6AfXdmo78V55rKCt0oiXtsWbYeWLo7Dn1EQmug3mgY00Hfad5A UqAtbTh8GOGyuE7FkFTphEMXpCRLPBf2zUEw+tqoN9nXWEuC/pHu6VCGpSiZjOlqhUFS +9HIVm8j3LiZ9ePUltbd/53t11I1RAkl31GhDsjLYqrnL182fzwHbD7CfO+oqFg8pYv8 K3yw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742501371; x=1743106171; 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=HHkf0HBgHGIV6HCG7t6tjumqai+IBk2OP83pNwikXNM=; b=CIDdBlb0FwBkRwjdi+f1ClqAGUYDFkFpk6VyfIbV6MyUt7UM+76vOCW5Vts54fxKrr xxNVudEwxQaSlRF+FwCidQqLPFm7ahGjEilLR7CRESGTGbvU2NlFx6YIJoVusyAdsJCg 3xjSFy3QM4pXR/Ma2KtNZtOZfpGXuMsLtsttBdoZG7UeX6D8BRIulftmbdSSs3tx2/VH +IBckiEVVAMhgnUdY2DpR8+h5c/yAtRww7NR1Co6xiaXNOjR0RWMWGMUyp3bGJEM2QLv pSsDjB52duM73LcN5gl95Nwdfznn7jiJdO2maoEeUkD2uWCCtkn29PoOQmY/ugFDqTgO LOOA== X-Forwarded-Encrypted: i=1; AJvYcCVCJkUswTKAEWKvGh97C+sTCbRXOuPjo8gmZv9FA3rd0BxKqOR60oFk2sdkHd2FeXOJ2V4kxwYrI7e2Dv6q@postgresql.org X-Gm-Message-State: AOJu0YzZELmEqeR6ge3hc6brCePfBXkWQW9oV0aVhC2bc7WQJ0clIfBE k4eUQJxejKgIVyaifqNjxk/GglyI5Wbo9c6zLrYQqfc1w2DO9kNpHxxTdm/iqjvEF6iNMlrYdcQ /Qj9Q0cKyUnXW4pgAWHr2HRa/mm0= X-Gm-Gg: ASbGncu0y/9LdszF98DEEhfabM/zUBfoEE/VtxhNcFzD9sHcfRKfYA8P6b3takWlQSW AbbM14iREvw386dwkyAn0/Sec6MSjhhZo7XEjI33L1s71ZVHbO4fXKFm7z5zbyInBScmqy3tncz UiVWHWOoiG8q/h0CJtSUzjn2pu X-Google-Smtp-Source: AGHT+IEHkmOBgM/HM9SYacUfzek5jnWgy0UIMnorP7byrvi0YjlEiaGgttZ6B/9e5sbuc5OFsWMuH5UHlis3oVxVUHQ= X-Received: by 2002:a05:6870:470e:b0:2bd:456c:923 with SMTP id 586e51a60fabf-2c7802d4edcmr592307fac.11.1742501370970; Thu, 20 Mar 2025 13:09:30 -0700 (PDT) MIME-Version: 1.0 References: <202503201748.wxkazqupyvuk@alvherre.pgsql> <1092933.1742496844@sss.pgh.pa.us> In-Reply-To: <1092933.1742496844@sss.pgh.pa.us> From: "David G. Johnston" Date: Thu, 20 Mar 2025 13:08:54 -0700 X-Gm-Features: AQ5f1JrR7AnSzxkItWAnUkAAtlmUpA5xn1h3Nec1aA4rjN8paEIbtloUtxvlnJA 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="0000000000003ccd0a0630cbb757" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000003ccd0a0630cbb757 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Mar 20, 2025 at 11:54=E2=80=AFAM Tom Lane wrote= : > =3D?utf-8?Q?=3DC3=3D81lvaro?=3D Herrera writes: > > That said, we could add a comment that makes this more obvious: > > ... > > This looks a tad redundant in pg_type.h itself, but makes the generated > > pg_type_d.h file more obvious: > > 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 */ > > for this part, and I'm not sure what other parts would be useful > to label. > 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 type. I think any other useful comments we'd want to include could be sufficiently handled with one added general facility: /*------------------------------------------------------------------------- * * %s * %s * * Portions Copyright (c) 1996-2025, PostgreSQL Global Development Group * Portions Copyright (c) 1994, Regents of the University of California * * NOTES * ****************************** * *** DO NOT EDIT THIS FILE! *** * ****************************** * * It has been GENERATED by src/backend/catalog/genbki.pl * *------------------------------------------------------------------------- * %s - have a spot in the *.h files to write some additional comments and then inject them here if present */ I'm not going to dive deep enough to make more targeted suggestions. It does seem, though, that "client code" would seem mostly interested in these OIDs and not stuff like the attribute numbers of the columns in pg_type. I get a distinct feel of one file serving multiple use cases. > As for CASHOID and LSNOID, surely those have been deprecated long > enough that we could just remove them? > > I'd probably just leave them. David J. --0000000000003ccd0a0630cbb757 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Mar 20, 2025 at 11:54=E2=80=AFAM Tom Lane <tgl@sss.pgh.pa.us> wrote:
=3D?utf-8?Q?=3DC3=3D81lvaro?=3D Herrera &l= t;alvherre@alv= h.no-ip.org> writes:
> That said, we could add a comment that makes this more obvious:
> ...
> This looks a tad redundant in pg_type.h itself, but makes the generate= d
> pg_type_d.h file more obvious:

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 thinking 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 */

for this part, and I'm not sure what other parts would be useful
to label.

I'd consider this enou= gh for the moment, so long as we explicitly address the cross-version const= ancy=C2=A0of the OID values associated with each type.

I think any other=C2=A0useful comments we'd want to include could be s= ufficiently handled with one added general facility:

/= *-------------------------------------------------------------------------<= br>=C2=A0*
=C2=A0* %s
=C2=A0* =C2=A0 =C2=A0%s
=C2=A0*
=C2=A0* P= ortions Copyright (c) 1996-2025, PostgreSQL Global Development Group
=C2= =A0* Portions Copyright (c) 1994, Regents of the University of California=C2=A0*
=C2=A0* NOTES
=C2=A0* =C2=A0******************************<= br>=C2=A0* =C2=A0*** DO NOT EDIT THIS FILE! ***
=C2=A0* =C2=A0**********= ********************
=C2=A0*
=C2=A0* =C2=A0It has been GENERATED by s= rc/backend/catalog/genbki.pl
=C2=A0*=C2=A0*-------------------------------------------------------------------= ------
=C2=A0* %s - have a spot in the *.h files to write some addi= tional comments and then inject them here if present
=C2=A0*/

I'm not going to dive deep enough to make more targete= d suggestions.=C2=A0 It does seem, though, that "client code" wou= ld seem mostly interested in these OIDs and not stuff like the attribute nu= mbers of the columns in pg_type.=C2=A0 I get a distinct feel of one file se= rving multiple use cases.


As for CASHOID and LSNOID, surely those have been deprecated long
enough that we could just remove them?


<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ">I'd probably just leave them.

David J.
<= br>
--0000000000003ccd0a0630cbb757--