| From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
|---|---|
| To: | Daniel Verite <daniel(at)manitou-mail(dot)org>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Supporting non-deterministic collations with tailoring rules. |
| Date: | 2026-03-18 08:12:33 |
| Message-ID: | bbe2d768-d82b-4145-b5e4-a20c26a5b47c@eisentraut.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 15.03.26 19:52, Daniel Verite wrote:
> [resent for the list]
>
> Peter Eisentraut wrote:
>
>>> To me, the most plausible fix on the Postgres side would be to pass
>>> UCOL_DEFAULT instead of UCOL_DEFAULT_STRENGTH as in the attached,
>>> which lets the user specify the strength in the rule, as the OP did in [1].
>>
>> With this change, I don't see that the bug reported in ICU-22456 is
>> fixed. See attached my test case.
>>
>> What change of behavior are you expecting from your patch? Should there
>> be test cases?
>
> Indeed it does not fix the behavior reported in ICU-22456
> (=collation properties being "reset" when adding rules)
> It fixes the fact that specificying the strength in the rule itself
> will be taken into account instead of the strength being
> forced to tertiary.
>
> PFA a new patch with a specific test case added.
>
> With regards to reports on pgsql-bugs, it fixes #18771
> and the second part of #19425.
> It does not fix #19045, which looks the same as ICU-22456
> It also does not fix the first part of #19425 (which looks the
> same as #19045). We cannot fix that in Postgres AFAIU.
> However adding the strength or other collation properties in
> the rules can be used as a workaround against the ICU-22456
> issue, provided the attached change is made.
Ok, committed.
Thoughts on backpatching? Seems like a straightforward bug fix.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2026-03-18 08:14:21 | Re: Skipping schema changes in publication |
| Previous Message | Heikki Linnakangas | 2026-03-18 08:06:23 | Re: Changing the state of data checksums in a running cluster |