Re: hashing bpchar for nondeterministic collations is broken
| От | Richard Guo |
|---|---|
| Тема | Re: hashing bpchar for nondeterministic collations is broken |
| Дата | |
| Msg-id | CAMbWs48dYCWaMaPxFCC4hDTf5ZOFX1xcDdAs4kuPq1b7CCTDAA@mail.gmail.com обсуждение исходный текст |
| Ответ на | hashing bpchar for nondeterministic collations is broken (Jeff Davis <pgsql@j-davis.com>) |
| Ответы |
Re: hashing bpchar for nondeterministic collations is broken
|
| Список | pgsql-bugs |
On Fri, Dec 2, 2022 at 4:11 AM Jeff Davis <pgsql@j-davis.com> wrote:
CREATE COLLATION ctest_nondet(
provider = icu, locale = '', deterministic = false);
=# select hashbpcharextended('a' collate ctest_nondet, 3);
hashbpcharextended
---------------------
2792701603979490504
(1 row)
=# select hashbpcharextended('a ' collate ctest_nondet, 3);
hashbpcharextended
----------------------
-4885217598372536483
(1 row)
Good catch. This really shouldn't happen for bpchar as the trailing
blanks are supposed to be ignored. I can see hashbpchar is doing it
with the correct "true" length, so maybe this is a copy-and-pasteo from
hashtextextended?
blanks are supposed to be ignored. I can see hashbpchar is doing it
with the correct "true" length, so maybe this is a copy-and-pasteo from
hashtextextended?
Also, does someone have an opinion on backporting this? I'm inclined
to.
I'm not familiar with the backporting policy, but I also think we need
to as this fixes an obvious oversight.
Thanks
Richard
to as this fixes an obvious oversight.
Thanks
Richard
В списке pgsql-bugs по дате отправления: