Re: Dump/Restore of non-default PKs - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Dump/Restore of non-default PKs
Date
Msg-id 3688375.1650636863@sss.pgh.pa.us
Whole thread Raw
In response to Re: Dump/Restore of non-default PKs  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Responses Re: Dump/Restore of non-default PKs  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
List pgsql-hackers
Peter Eisentraut <peter.eisentraut@enterprisedb.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



pgsql-hackers by date:

Previous
From: Bharath Rupireddy
Date:
Subject: Re: How to generate a WAL record spanning multiple WAL files?
Next
From: Bharath Rupireddy
Date:
Subject: Re: why pg_walfile_name() cannot be executed during recovery?