Horton

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

Laurenz Albe <laurenz.albe@cybertec.at>

View thread
From: Laurenz Albe <laurenz.albe@cybertec.at>
To: Paul A Jungwirth <pj@illuminatedcomputing.com>, Tom Lane <tgl@sss.pgh.pa.us>
Cc: n.bartek3762@gmail.com, pgsql-bugs@lists.postgresql.org, Peter Eisentraut <peter@eisentraut.org>, Matthias van de Meent <boekewurm+postgres@gmail.com>
Date: 2025-10-30T10:30:13Z
Lists: 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