Re: Dump/Restore of non-default PKs
| От | Peter Eisentraut |
|---|---|
| Тема | Re: Dump/Restore of non-default PKs |
| Дата | |
| Msg-id | 62224288-cbc0-a759-4ff6-40baa32943eb@enterprisedb.com обсуждение исходный текст |
| Ответ на | Re: Dump/Restore of non-default PKs (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: Dump/Restore of non-default PKs
|
| Список | pgsql-hackers |
On 18.04.22 22:48, Tom Lane wrote: >> Why not just get rid of the limitation that constraint definitions don't >> support non-default methods? > That approach would be doubling down on the assumption that we can always > shoehorn more custom options into SQL-standard constraint clauses, and > we'll never fall foul of shift/reduce problems or future spec additions. When we do get the ability to create a table with a primary key with an underlying hash index, how would that be done? Would the only way be 1. create the table without primary key 2. create the index 3. attach the index as primary key constraint That doesn't sound attractive.
В списке pgsql-hackers по дате отправления: