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