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
-
Teach hash_ok_operator() that record_eq is only sometimes hashable.
- 647889667566 15.0 landed
- 17da9d4c2829 14.2 landed