From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
Cc: | Simon Riggs <simon(dot)riggs(at)enterprisedb(dot)com>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Dump/Restore of non-default PKs |
Date: | 2022-04-22 14:14:23 |
Message-ID: | 3688375.1650636863@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> writes:
> On 21.04.22 13:43, Simon Riggs wrote:
>> Can you explain what you find unattractive about it?
> Well, if I want to create a table with a primary key, the established
> way is to say "primary key", not to have to assemble it from multiple
> pieces.
> I think this case is very similar to exclusion constraints, which also
> have syntax to specify the index access method.
That analogy would be compelling if exclusion constraints were a
SQL-standard feature; but they aren't so their clause syntax is
fully under our control. The scenario that worries me is that
somewhere down the pike, the SQL committee might extend the
syntax of PKEY/UNIQUE constraint clauses in a way that breaks
our nonstandard extensions of them.
However, independently of whether we offer a syntax option or not,
it may still simplify pg_dump to make it treat the constraint and
the index as independent objects in all cases.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bharath Rupireddy | 2022-04-22 14:15:14 | Re: why pg_walfile_name() cannot be executed during recovery? |
Previous Message | Tom Lane | 2022-04-22 14:04:05 | Re: pgsql: Allow db.schema.table patterns, but complain about random garbag |