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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
Cc: David Rowley <dgrowleyml(at)gmail(dot)com>, sait(dot)nisanci(at)microsoft(dot)com, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: BUG #17158: Distinct ROW fails with Postgres 14
Date: 2021-08-31 20:43:54
Message-ID: 2021952.1630442634@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> writes:
> 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.

Hmm.

> 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.

I find variant 1 a bit cleaner, and safer. I'd rather default to
assuming that RECORD doesn't hash, when we don't have enough info
to be sure.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2021-09-01 02:25:31 BUG #17172: NaN compare error in hash agg
Previous Message Tom Lane 2021-08-31 20:10:53 Re: BUG #17170: Invalid collation created with provider icu and initdb' locale C