On Thu, Mar 20, 2025 at 11:54 AM Tom Lane <tgl@xxxxxxxxxxxxx> wrote:
=?utf-8?Q?=C3=81lvaro?= Herrera <alvherre@xxxxxxxxxxxxxx> 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
* %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.
