On Wed, 20 Apr 2022 at 21:46, Peter Eisentraut
<peter.eisentraut@enterprisedb.com> wrote:
>
> 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.
Can you explain what you find unattractive about it?
The alternative is we have this
1. create the table without primary key
2. attach the index as primary key constraint (which must be extended
to include ALL of the options available on create index)
Having to extend ALTER TABLE so it exactly matches CREATE INDEX is
painful and maintaining it that way seems unattractive, to me.
Just so we are clear this is not about hash indexes, this is about
using ANY kind of index (i.e. any index access method, extension or
otherwise) to enforce a constraint.
Another idea might be to allow some kind of statement embedding... so
we don't need to constantly fiddle with ALTER TABLE
ALTER TABLE foo ADD PRIMARY KEY USING INDEX (CREATE INDEX .... )
--
Simon Riggs http://www.EnterpriseDB.com/
