| From: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
| Cc: | Simon Riggs <simon(dot)riggs(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Dump/Restore of non-default PKs |
| Date: | 2022-04-20 20:46:35 |
| Message-ID: | 62224288-cbc0-a759-4ff6-40baa32943eb@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas Munro | 2022-04-20 20:51:31 | Re: pg14 psql broke \d datname.nspname.relname |
| Previous Message | Tom Lane | 2022-04-20 20:45:27 | renumber_oids.pl needs some updates |