Re: BUG #19098: Can't create unique gist index, where pg_indexes says that WITHOUT OVERLAPS does exacly that - Mailing list pgsql-bugs

From Laurenz Albe
Subject Re: BUG #19098: Can't create unique gist index, where pg_indexes says that WITHOUT OVERLAPS does exacly that
Date
Msg-id 0e8907d8a0cb19b64d732ec7b44f8eb669b54075.camel@cybertec.at
Whole thread Raw
In response to Re: BUG #19098: Can't create unique gist index, where pg_indexes says that WITHOUT OVERLAPS does exacly that  (Paul A Jungwirth <pj@illuminatedcomputing.com>)
Responses Re: BUG #19098: Can't create unique gist index, where pg_indexes says that WITHOUT OVERLAPS does exacly that
List pgsql-bugs
On Wed, 2025-10-29 at 11:51 -0700, Paul A Jungwirth wrote:
> So here is a proposed sequence of work:
>
> - Add an opclass_parameter so you can say without_overlaps = true.
> Only the last column of the index allows that (at least for now), and
> there must be an overlaps operator.
> - If an index has that property, enforce the exclusion constraint
> rules and forbid empty ranges/multiranges.
> - Update pg_get_indexdef to output the right syntax to create an
> independent temporal index.
> - Allow USING INDEX for WITHOUT OVERLAPS. It must be a temporal index.
> - Support can_unique in GiST indexes using CompareType. (Perhaps this
> is of low practical value, but the discrepancies bug me.)
> - Add can_temporal to index AMs. Make GiST report true. Check this
> property instead of hard-coding GiST in our WITHOUT OVERLAPS code.
> - Support reindexing these indexes concurrently. (I'm not signing up
> for this just yet, but maybe someday.)
> - Support creating these indexes concurrently. (I'm not signing up for
> this just yet, but maybe someday.)

That's perhaps a good way for the future, but the cat is already out
of the bag.  Do you have any ideas what to do about v18?

Yours,
Laurenz Albe



pgsql-bugs by date:

Previous
From: Lori Corbani
Date:
Subject: RE: [EXTERNAL]Re: BUG #19094: select statement on postgres 17 vs postgres 18 is returning different/duplicate results
Next
From: Thomas Munro
Date:
Subject: Re: [EXTERNAL]Re: BUG #19094: select statement on postgres 17 vs postgres 18 is returning different/duplicate results