From: Tom Lane <tgl@sss.pgh.pa.us>
To: Paul A Jungwirth <pj@illuminatedcomputing.com>
cc: Laurenz Albe <laurenz.albe@cybertec.at>, n.bartek3762@gmail.com,
        pgsql-bugs@lists.postgresql.org,
        Peter Eisentraut <peter@eisentraut.org>,
        Matthias van de Meent <boekewurm+postgres@gmail.com>
Subject: Re: BUG #19098: Can't create unique gist index,
 where pg_indexes says that WITHOUT OVERLAPS does exacly that
In-reply-to: 
 <CA+renyVFvUeCFeNYqkoQ4Sx+J9Wn+M3wqhtxuWVEpExvJYjsHQ@mail.gmail.com>
References: <19098-7f8deb5093c13da2@postgresql.org>
 <11e73b0d2d89476fb04e6055a80638f776bb6f18.camel@cybertec.at>
 <2748212.1761750444@sss.pgh.pa.us> <2750966.1761751813@sss.pgh.pa.us>
 <CA+renyV3dxf8TSEG7C0vpwwFDr67KF=FGCTZ8ZrXWxOK-T1vfw@mail.gmail.com>
 <0e8907d8a0cb19b64d732ec7b44f8eb669b54075.camel@cybertec.at>
 <CA+renyVFvUeCFeNYqkoQ4Sx+J9Wn+M3wqhtxuWVEpExvJYjsHQ@mail.gmail.com>
Comments: In-reply-to Paul A Jungwirth <pj@illuminatedcomputing.com>
	message dated "Thu, 30 Oct 2025 10:20:54 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3329403.1761849077.1@sss.pgh.pa.us>
Date: Thu, 30 Oct 2025 14:31:17 -0400
Message-ID: <3329404.1761849077@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/3329404.1761849077%40sss.pgh.pa.us>
Precedence: bulk

Paul A Jungwirth <pj@illuminatedcomputing.com> writes:
> 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.

> 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?

I think that's too much risk and churn for v18 at this point.
Even if we risked putting in such a patch, we'd have a situation
where pg_get_indexdef in later v18 minor releases would output
syntax that's rejected by earlier minor releases, which would
be a mess.

My feeling is that pg_get_indexdef is broken for these indexes, but
there's nothing we can do now to improve that in v18.  The important
thing is to make sure it gets fixed for 19.

			regards, tom lane