From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
---|---|
To: | sait(dot)nisanci(at)microsoft(dot)com, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
Subject: | Re: BUG #17158: Distinct ROW fails with Postgres 14 |
Date: | 2021-08-24 09:55:18 |
Message-ID: | CAApHDvp0w_5YY=7pxPkymtv7Oc0cGS=+jtiBvXrfcM6gLjT5Pg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Tue, 24 Aug 2021 at 21:02, PG Bug reporting form
<noreply(at)postgresql(dot)org> wrote:
> -- This works fine before pg14.
> SELECT DISTINCT ROW(col1, col2, col3, col4, col5, col6, col70, col7, col8,
> col9, col10,
> col11, col12, col13, col14, col15, col16, col17, col18, col19, col20, col21,
> col22, col23, col24, col25,
> col26, col27, col28, col29, col32, col33, col34, col35, col36, col37, col38)
> AS "row" FROM local WHERE true;
> ERROR: could not identify a hash function for type bit
It looks like 01e658fa74 is to blame for this.
The test case can be simplified down to just:
create table local (b bit);
insert into local values('1'),('0');
SELECT DISTINCT ROW(b) FROM local;
Tom did have a look at this and raise the question about the
possibility of not being able to hash in [1].
If it's going to be a problem detecting the lack of hashability during
planning then maybe we can just add a hash opclass for BIT to fix this
particular case.
I've copied in Peter as 01e658fa74 is one of his.
David
[1] https://www.postgresql.org/message-id/20201019233234.r6lyxbvdg5s77rvd%40alap3.anarazel.de
From | Date | Subject | |
---|---|---|---|
Next Message | Ashutosh Kumar | 2021-08-24 10:01:52 | RE: BUG #17156: pg_restore: [custom archiver] WARNING: ftell mismatch with expected position -- ftell used |
Previous Message | PG Bug reporting form | 2021-08-24 08:46:46 | BUG #17158: Distinct ROW fails with Postgres 14 |