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.