On Tue, Oct 6, 2020 at 4:16 PM Andres Freund <and...@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
