From: Tom Lane <tgl@sss.pgh.pa.us>
To: elprans@gmail.com
Cc: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Cc: 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
Date: Wed, 12 Jan 2022 10:34:55 -0500
Message-ID: <2998707.1642001695@sss.pgh.pa.us> (raw)
In-Reply-To: <17363-f6d42fd0d726be02@postgresql.org>
References: <17363-f6d42fd0d726be02@postgresql.org>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, elprans@gmail.com, 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: <2998707.1642001695@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox