Re: BUG #17158: Distinct ROW fails with Postgres 14

On 25.08.21 00:16, Tom Lane wrote:
> Undoing that would lose v14's ability to select hashed duplicate
> elimination for RECORD columns, but that's still not a regression
> because we didn't have it before. Moreover, anyone who's unhappy can
> work around the problem by explicitly casting the column to some
> suitable named composite type. We can leave it for later to make the
> planner smarter about anonymous record types. It clearly could be
> smarter, at least for the case of an explicit ROW construct at top
> level; but now is no time to be writing such code for v14.

This feature is a requirement for multicolumn path and cycle tracking in
recursive queries, as well as the search/cycle syntax built on top of
that, so there is a bit more depending on it than might be at first
apparent.

I've been looking at ways to repair this with minimal impact.
Essentially, we'd need a way ask the type cache to distinguish between
"do you have hash support if it's guaranteed to work" versus "hash
support is my only hope, so give it to me even if you're not completely
sure it will work". Putting this directly into the type cache does not
seem feasible with the current structure. But there aren't that many
callers of TYPECACHE_HASH_PROC*, so I looked at handling it there.

Variant 1 is that we let the type cache *not* report hash support for
the record type, and let callers fill it in. In the attached patch I've
only done this for hash_array(), because that's what's needed to get the
tests to pass, but similar code would be possible for row types, range
types, etc.

Variant 2 is that we let the type cache report hash support for the
record type, like now, and then let callers override it if they have
other options. This is the second attached patch.

It's basically fifty-fifty in terms of how many places you need to touch
in either case.

With both patches, you'll see the "union" regression test fail, which
includes a test case that is equivalent to the one from this bug report
(but using money instead of bit), but the "with" test still passes,
which covers the feature I mentioned at the beginning.

Thoughts?