pg.ddx.io pgsql-bugs@postgresql.org mailing list archive
help / color / mirror / Atom feedBUG #17363: 14 regression: "could not identify a hash function for type record" in a nested record in sublink
3+ messages / 2 participants
[nested] [flat]
* BUG #17363: 14 regression: "could not identify a hash function for type record" in a nested record in sublink
@ 2022-01-11 22:46 PG Bug reporting form <noreply@postgresql.org>
2022-01-12 15:34 ` 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>
0 siblings, 1 reply; 3+ messages in thread
From: PG Bug reporting form @ 2022-01-11 22:46 UTC (permalink / raw)
To: pgsql-bugs@lists.postgresql.org; +Cc: elprans@gmail.com
The following bug has been logged on the website:
Bug reference: 17363
Logged by: Elvis Pranskevichus
Email address: elprans@gmail.com
PostgreSQL version: 14.0
Operating system: Linux
Description:
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:
postgres13=# SELECT ROW(ROW(ROW(1))) = ANY (SELECT
(ROW(ROW(ROW(1)))).*);
?column?
──────────
t
(1 row)
Interestingly, reducing the nesting level to two works in 14:
postgres14=# SELECT ROW(ROW(1)) = ANY (SELECT (ROW(ROW(1))).*);
?column?
──────────
t
(1 row)
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: BUG #17363: 14 regression: "could not identify a hash function for type record" in a nested record in sublink
2022-01-11 22:46 BUG #17363: 14 regression: "could not identify a hash function for type record" in a nested record in sublink PG Bug reporting form <noreply@postgresql.org>
@ 2022-01-12 15:34 ` Tom Lane <tgl@sss.pgh.pa.us>
2022-01-16 21:00 ` 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>
0 siblings, 1 reply; 3+ messages in thread
From: Tom Lane @ 2022-01-12 15:34 UTC (permalink / raw)
To: elprans@gmail.com; +Cc: Peter Eisentraut <peter.eisentraut@enterprisedb.com>; pgsql-bugs@lists.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
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: BUG #17363: 14 regression: "could not identify a hash function for type record" in a nested record in sublink
2022-01-11 22:46 BUG #17363: 14 regression: "could not identify a hash function for type record" in a nested record in sublink PG Bug reporting form <noreply@postgresql.org>
2022-01-12 15:34 ` 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>
@ 2022-01-16 21:00 ` Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 3+ messages in thread
From: Tom Lane @ 2022-01-16 21:00 UTC (permalink / raw)
To: Peter Eisentraut <peter.eisentraut@enterprisedb.com>; +Cc: elprans@gmail.com; pgsql-bugs@lists.postgresql.org
I wrote:
> 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.
Ugh, found it: hash_ok_operator() is not accounting for this case.
if (opid == ARRAY_EQ_OP)
{
/* array_eq is strict, but must check input type to ensure hashable */
/* XXX record_eq will need same treatment when it becomes hashable */
Node *leftarg = linitial(expr->args);
return op_hashjoinable(opid, exprType(leftarg));
}
Will fix.
regards, tom lane
^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2022-01-16 21:00 UTC | newest]
Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2022-01-11 22:46 BUG #17363: 14 regression: "could not identify a hash function for type record" in a nested record in sublink PG Bug reporting form <noreply@postgresql.org>
2022-01-12 15:34 ` Tom Lane <tgl@sss.pgh.pa.us>
2022-01-16 21:00 ` Tom Lane <tgl@sss.pgh.pa.us>
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