Re: Supporting non-deterministic collations with tailoring rules.

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.

In response to

Responses

Browse pgsql-hackers by date

  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