renumber_oids.pl needs some updates
I did a test run of renumber_oids.pl to see if there would be any
problems when the time comes (pretty soon!) to run it for v15.
Depressingly enough, I found two problems:
1. When commit dfb75e478 invented DECLARE_UNIQUE_INDEX_PKEY,
it neglected to teach renumber_oids.pl about it. I'm surprised
we did not notice this last year.
2. renumber_oids.pl failed miserably on pg_parameter_acl.h:
@@ -48,11 +48,11 @@ CATALOG(pg_parameter_acl,8924,ParameterAclRelationId) BKI_SHARED_RELATION
*/
typedef FormData_pg_parameter_acl *Form_pg_parameter_acl;
-DECLARE_TOAST(pg_parameter_acl, 8925, 8926);
+DECLARE_TOAST(pg_parameter_acl, 6244, 6245);
#define PgParameterAclToastTable 8925
#define PgParameterAclToastIndex 8926because of course it didn't know it should update the
PgParameterAclToastTable and PgParameterAclToastIndex macro definitions.
(We have this same coding pattern elsewhere, but I guess that
renumber_oids.pl has never previously been asked to renumber a shared
catalog.)
I think the right way to fix #2 is to put the responsibility for
generating the #define's into genbki.pl, instead of this mistake-prone
approach of duplicating the OID constants in the source code.
The attached proposed patch invents a variant macro
DECLARE_TOAST_WITH_MACRO for the relatively small number of cases
where we need such OID macros. A different idea could be to require
all the catalog headers to define C macros for their toast tables
and change DECLARE_TOAST to a five-argument macro across the board.
However, that would require touching a bunch more places and inventing
a bunch more macro names, and it didn't really seem useful.
Thoughts?
regards, tom lane
Attachments:
generate-toast-table-oid-macros-1.patchtext/x-diff; charset=us-ascii; name=generate-toast-table-oid-macros-1.patchDownload+58-32
On 20.04.22 22:45, Tom Lane wrote:
I think the right way to fix #2 is to put the responsibility for
generating the #define's into genbki.pl, instead of this mistake-prone
approach of duplicating the OID constants in the source code.The attached proposed patch invents a variant macro
DECLARE_TOAST_WITH_MACRO for the relatively small number of cases
where we need such OID macros.
This makes sense.
A more elaborate (future) project would be to have genbki.pl generate
all of IsSharedRelation(), which is the only place these toast-table-OID
macros are used, AFAICT.
Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
On 20.04.22 22:45, Tom Lane wrote:
The attached proposed patch invents a variant macro
DECLARE_TOAST_WITH_MACRO for the relatively small number of cases
where we need such OID macros.
This makes sense.
A more elaborate (future) project would be to have genbki.pl generate
all of IsSharedRelation(), which is the only place these toast-table-OID
macros are used, AFAICT.
Perhaps. We invent shared catalogs at a slow enough rate that I'm
not sure the effort would ever pay for itself in person-hours,
but maybe making such invention a trifle less error-prone is
worth something.
I'd still want to keep this form of DECLARE_TOAST, in case someone
comes up with a different reason to want macro names for toast OIDs.
regards, tom lane