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

On Thu, Oct 30, 2025 at 3:30 AM Laurenz Albe <laurenz.albe@cybertec.at> wrote:
>
> 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?

Doing the first 3 items here would fix pg_get_indexdef. The hard one
is the second, but I will work on a patch for it. Is that something
we'd want to release as a patch to v18?

Yours,

--
Paul              ~{:-)
pj@illuminatedcomputing.com