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

From Simon Riggs
Subject Re: Dump/Restore of non-default PKs
Date
Msg-id CANbhV-Fq8JmAdSE4jsBU-wd1vj6aZuQKGm_9JqwD=S5DeoGmvQ@mail.gmail.com
Whole thread Raw
In response to Re: Dump/Restore of non-default PKs  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
List pgsql-hackers
On Thu, 28 Apr 2022 at 15:09, Peter Eisentraut
<peter.eisentraut@enterprisedb.com> wrote:
>
> On 22.04.22 16:14, Tom Lane wrote:
> > 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.
>
> Some syntax like
>
>      PRIMARY KEY (x, y) USING ACCESS METHOD hash
>
> should be able to avoid any future clashes.

That seems to conflict with USING INDEX TABLESPACE. I've tried a few
things but have not found anything yet.

Any other ideas on syntax?

-- 
Simon Riggs                http://www.EnterpriseDB.com/



pgsql-hackers by date:

Previous
From: Justin Pryzby
Date:
Subject: Re: [Commitfest 2022-07] Patch Triage: Waiting on Author
Next
From: Önder Kalacı
Date:
Subject: Re: [PATCH] Use indexes on the subscriber when REPLICA IDENTITY is full on the publisher