Re: Add primary keys to system catalogs - Mailing list pgsql-hackers

From John Naylor
Subject Re: Add primary keys to system catalogs
Date
Msg-id CAFBsxsE=-WP2tYU5=D-_Qcyf0aWtdsp9YvzL5qcrYyt=GxcZgg@mail.gmail.com
Whole thread Raw
In response to Re: Add primary keys to system catalogs  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers

On Tue, Oct 6, 2020 at 4:16 PM Andres Freund <andres@anarazel.de> wrote:
True, we don't create new ones that often. Still think that distributing
such setup over fewer places is good. And it's not like there's only a
handful of pkeys to start with. To me it makes more sense to add a
DECLARE_PRIMARY_KEY in indexing.h, replacing the relevant
DECLARE_UNIQUE_INDEX stanzas.

That seems logical.
 
Or, possibly preferrable, do it as part of
the CATALOG() directly - which'd avoid needing the index statement in
the first place.

That line is already messy in places. AFAICT, you'd still need info from the index statement (at least my shortened version below), leading to two syntaxes and two places for the same thing. Maybe I'm missing something?
 
Wonder whether it's not time to move the DECLARE bits from indexing.h to
the individual catalogs, independent of what we're discussing here. With
todays Catalog.pm there's really not much point in keeping them
separate, imo.

That would look nicer, at least. A declaration could go from

DECLARE_UNIQUE_INDEX(pg_subscription_rel_srrelid_srsubid_index, 6117, on pg_subscription_rel using btree(srrelid oid_ops, srsubid oid_ops));
#define SubscriptionRelSrrelidSrsubidIndexId 6117

to something like

DECLARE_UNIQUE_INDEX(btree(srrelid oid_ops, srsubid oid_ops), 6117, SubscriptionRelSrrelidSrsubidIndexId));

--
John Naylor
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company 

pgsql-hackers by date:

Previous
From: Dilip Kumar
Date:
Subject: Re: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables
Next
From: Amit Kapila
Date:
Subject: Re: Resetting spilled txn statistics in pg_stat_replication