From: Tom Lane <tgl@sss.pgh.pa.us>
To: elprans@gmail.com
cc: Peter Eisentraut <peter.eisentraut@enterprisedb.com>,
        pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17363: 14 regression: "could not identify a hash function
 for type record" in a nested record in sublink
In-reply-to: <17363-f6d42fd0d726be02@postgresql.org>
References: <17363-f6d42fd0d726be02@postgresql.org>
Comments: In-reply-to PG Bug reporting form <noreply@postgresql.org>
	message dated "Tue, 11 Jan 2022 22:46:02 +0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2998706.1642001695.1@sss.pgh.pa.us>
Date: Wed, 12 Jan 2022 10:34:55 -0500
Message-ID: <2998707.1642001695@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2998707.1642001695%40sss.pgh.pa.us>
Precedence: bulk

PG Bug reporting form <noreply@postgresql.org> writes:
> The following fails in PostgreSQL 14:

>   postgres14=# SELECT ROW(ROW(ROW(1))) = ANY (SELECT (ROW(ROW(ROW(1)))).*);
>   ERROR:  could not identify a hash function for type record

> whereas PostgreSQL 13 works fine:

It appears that we're trying to use a hashed subplan for the =ANY,
where v13 did not.  So I'm inclined to blame this on 01e658fa7 (Hash
support for row types).  We backed off the optimism level a bit in
a3d2b1bbe (Disable anonymous record hash support except in special
cases), but evidently didn't go far enough; or else it's doing the
wrong thing for nested RECORD types.

			regards, tom lane