Re: Add primary keys to system catalogs

On Tue, Oct 6, 2020 at 4:16 PM Andres Freund <andres(at)anarazel(dot)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