From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrei Lepikhov <lepihov@gmail.com>
cc: pgsql-bugs@lists.postgresql.org, Peter Eisentraut <peter@eisentraut.org>
Subject: Re: Hashed SAOP on composite type with non-hashable column errors at
 runtime
In-reply-to: <89005dba-32f0-414b-9de9-30acbdbdd2f6@gmail.com>
References: <ed221f95-f09b-4a9c-b05b-e1fed621ec87@gmail.com>
 <3735597.1780683122@sss.pgh.pa.us>
 <89005dba-32f0-414b-9de9-30acbdbdd2f6@gmail.com>
Comments: In-reply-to Andrei Lepikhov <lepihov@gmail.com>
	message dated "Sun, 07 Jun 2026 19:56:32 +0200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <570737.1780934420.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Mon, 08 Jun 2026 12:00:20 -0400
Message-ID: <570738.1780934420@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/570738.1780934420%40sss.pgh.pa.us>
Precedence: bulk

Andrei Lepikhov <lepihov@gmail.com> writes:
> Now, hash_ok_operator and op_hashjoinable handle all four container-type
> equality operators. Side way is a C extension that lets you create a cus=
tom type
> that groups other types marked as HASHES.

Yeah, it's interesting to speculate about what we'd have to do to
allow extensions to invent new kinds of container types.  Right now,
the knowledge of what kinds of containers there are is wired into
a bunch of places.  This fix isn't adding any new places, just fixing
some places whose knowledge was incomplete.  So I'm content with this
for today.

> Fixes in the lookup_type_cache related to the multirange type are also c=
orrect
> for me. As well as pg_operator.dat changes.

Thanks for reviewing; I pushed v1-0001 after a bit more
comment-smithing.

>> I'm also unexcited about your 0002 and 0003.  =


> I understand about 0003, but what is the problem with 0002?

Let me rephrase that: 0002 is a new feature and hence out of scope
at this point in the development cycle.  If you want to start a
new thread proposing that for v20, go right ahead.

			regards, tom lane