Re: BUG #17363: 14 regression: "could not identify a hash function for type record" in a nested record in sublink

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: elprans@gmail.com
Cc: Peter Eisentraut <peter.eisentraut@enterprisedb.com>, pgsql-bugs@lists.postgresql.org
Date: 2022-01-12T15:34:55Z
Lists: pgsql-bugs
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



Commits

  1. Teach hash_ok_operator() that record_eq is only sometimes hashable.