From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Add primary keys to system catalogs |
Date: | 2020-10-06 19:31:16 |
Message-ID: | 1996232.1602012676@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2020-10-03 08:40:31 +0200, Peter Eisentraut wrote:
>> Since we have ADD PRIMARY KEY USING INDEX, we can declare a primary key for
>> an existing index. So this doesn't have to affect the low-level early
>> bootstrapping. The attached patch adds those commands manually. Another
>> option might be to have the catalog generation Perl tooling create those
>> declarations automatically from some marker in the catalog files. That
>> would also allow declaring unique constraints for the unique indexes that
>> don't end up being the primary key.
> Hm. What prevents us from declaring the pkey during bootstrap? I don't
> at all like adding yet another place that needs manual editing when
> doing DDL changes.
We don't add new catalogs often, so the cost-benefit ratio of automating
this looks pretty poor. It's not like you'll be able to forget to do it,
given the proposed regression test check for catalogs without pkeys.
One thing I'm wondering about though is whether Peter's implementation
ends up with desirable pg_depend contents for the pkey constraints.
Probably we want them to just be pinned and not have any explicit
dependencies on the associated indexes, but I haven't thought hard
about it.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2020-10-06 20:15:49 | Re: Add primary keys to system catalogs |
Previous Message | Bruce Momjian | 2020-10-06 19:05:09 | Re: pg_upgrade analyze script |