Horton

Thread

Commits

  1. Use DECLARE_TOAST_WITH_MACRO() to simplify toast-table declarations.

  2. Add primary keys and unique constraints to system catalogs

  1. renumber_oids.pl needs some updates

    Tom Lane <tgl@sss.pgh.pa.us> — 2022-04-20T20:45:27Z

    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 8926

because 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

  2. Re: renumber_oids.pl needs some updates

    Peter Eisentraut <peter.eisentraut@enterprisedb.com> — 2022-04-20T20:56:53Z

    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.

  3. Re: renumber_oids.pl needs some updates

    Tom Lane <tgl@sss.pgh.pa.us> — 2022-04-20T21:10:18Z

    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