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

From Tom Lane
Subject Re: BUG #17363: 14 regression: "could not identify a hash function for type record" in a nested record in sublink
Date
Msg-id 3820408.1642366844@sss.pgh.pa.us
Whole thread Raw
In response to 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>)
List pgsql-bugs
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



pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_upgrade --check doesn't check pg_pltemplate modifications
Next
From: Etsuro Fujita
Date:
Subject: Re: BUG #17355: Server crashes on ExecReScanForeignScan in postgres_fdw when accessing foreign partition