Re: Add primary keys to system catalogs
От | John Naylor |
---|---|
Тема | Re: Add primary keys to system catalogs |
Дата | |
Msg-id | CAFBsxsE=-WP2tYU5=D-_Qcyf0aWtdsp9YvzL5qcrYyt=GxcZgg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Add primary keys to system catalogs (Andres Freund <andres@anarazel.de>) |
Список | 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
#define SubscriptionRelSrrelidSrsubidIndexId 6117
to something like
DECLARE_UNIQUE_INDEX(btree(srrelid oid_ops, srsubid oid_ops), 6117, SubscriptionRelSrrelidSrsubidIndexId));
В списке pgsql-hackers по дате отправления: