From: Tom Lane <tgl@sss.pgh.pa.us>
To: pgsql-hackers@lists.postgresql.org
Subject: Re: Cross-type index comparison support in contrib/btree_gin
In-reply-to: <262624.1738460652@sss.pgh.pa.us>
References: <262624.1738460652@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Sat, 01 Feb 2025 20:44:12 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <360826.1738514833.1@sss.pgh.pa.us>
Date: Sun, 02 Feb 2025 11:47:13 -0500
Message-ID: <360827.1738514833@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/360827.1738514833%40sss.pgh.pa.us>
Precedence: bulk

I wrote:
> We've had multiple requests for $SUBJECT over the years
> ([1][2][3][4][5], and I'm sure my archive search missed some).
> I finally decided to look into what it'd take to make that happen.

I forgot to mention a couple of questions for review:

> ... it turns out that the
> comparePartial() method is only ever applied to compare the original
> query value with an index entry, which means that internally to
> comparePartial() we can apply the proper cross-type comparison
> operator.  Our GIN index documentation about comparePartial() doesn't
> quite say that in so many words, but btree_gin was already relying on
> it --- in a very confusing and ill-explained way, if you ask me, but
> it was relying on it.

Should we adjust the documentation of comparePartial() to promise
explicitly that partial_key is the same datum returned by extractQuery?
By my reading, it kind of implies that, but it's not quite black and
white.

> So basically all I had to do was write a bunch of non-error-throwing
> conversion routines and set up some boilerplate infrastructure.

In the 0005 patch, I relied on date2timestamp_opt_overflow and
its siblings where available.  But some of the conversions such
as timestamptz-to-timestamp don't have one of those, so I was
forced to copy-and-paste some fairly low-level code.  Would it
make sense to refactor the related core routines to expose
xxx2yyy_opt_overflow interfaces, extending what 5bc450629 and
52ad1e659 did?  I wouldn't think this worth doing just for
btree_gin's benefit, but if btree_gin needs it maybe some other
extensions could use it too.

			regards, tom lane