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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: elprans(at)gmail(dot)com
Cc: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #17363: 14 regression: "could not identify a hash function for type record" in a nested record in sublink
Date: 2022-01-12 15:34:55
Message-ID: 2998707.1642001695@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

PG Bug reporting form <noreply(at)postgresql(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2022-01-12 15:53:31 BUG #17364: Errors caused by views
Previous Message Tom Lane 2022-01-12 15:08:45 Re: wrong output in dump of rules with old values of row type columns