Re: BUG #17158: Distinct ROW fails with Postgres 14
От | David Rowley |
---|---|
Тема | Re: BUG #17158: Distinct ROW fails with Postgres 14 |
Дата | |
Msg-id | CAApHDvp0w_5YY=7pxPkymtv7Oc0cGS=+jtiBvXrfcM6gLjT5Pg@mail.gmail.com обсуждение исходный текст |
Ответ на | BUG #17158: Distinct ROW fails with Postgres 14 (PG Bug reporting form <noreply@postgresql.org>) |
Ответы |
Re: BUG #17158: Distinct ROW fails with Postgres 14
Re: BUG #17158: Distinct ROW fails with Postgres 14 |
Список | pgsql-bugs |
On Tue, 24 Aug 2021 at 21:02, PG Bug reporting form <noreply@postgresql.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
В списке pgsql-bugs по дате отправления: