Re: Dump/Restore of non-default PKs
От | Simon Riggs |
---|---|
Тема | Re: Dump/Restore of non-default PKs |
Дата | |
Msg-id | CANbhV-Fq8JmAdSE4jsBU-wd1vj6aZuQKGm_9JqwD=S5DeoGmvQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Dump/Restore of non-default PKs (Peter Eisentraut <peter.eisentraut@enterprisedb.com>) |
Список | 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 по дате отправления: