Re: Initcap works differently with different locale providers

Alexander Korotkov wrote at 2025-07-28 17:23:
> On Mon, Jul 28, 2025 at 1:20 PM Alexander Korotkov
> <aekorotkov@gmail.com> wrote:
>>
>> On 25 Sep 2024, at 18:13, Oleg Tselebrovskiy
>> <o.tselebrovskiy@postgrespro.ru> wrote:
>>
>> Greetings, everyone!
>>
>> One of our clients has found a difference in behaviour of initcap
>> function when
>> using different locale providers, shown below
>>
>> postgres=# create database test_db_1 locale_provider=icu
>> locale="ru_RU.UTF-8" template=template0;
>> NOTICE:  using standard form "ru-RU" for ICU locale "ru_RU.UTF-8"
>> CREATE DATABASE
>> postgres=# \c test_db_1;
>> You are now connected to database "test_db_1" as user "postgres".
>> test_db_1=# select initcap('ЧиЮ А.Ю.');
>> initcap
>> ----------
>> Чию А.ю.
>> (1 row)
>> test_db_1=# select initcap('joHn d.e.');
>> initcap
>> -----------
>> John D.e.
>> (1 row)
>> postgres=# create database test_db_2 locale_provider=libc
>> locale="ru_RU.UTF-8" template=template0;
>> CREATE DATABASE
>> postgres=# \c test_db_2
>> You are now connected to database "test_db_2" as user "postgres".
>> test_db_2=# select initcap('ЧиЮ А.Ю.');
>> initcap
>> ----------
>> Чию А.Ю.
>> (1 row)
>> test_db_2=# select initcap('joHn d.e.');
>> initcap
>> -----------
>> John D.E.
>> (1 row)
>>
>> And an easier reproduction (should work for REL_12_STABLE and up)
>>
>> postgres=# SELECT initcap('first.second' COLLATE "en-x-icu");
>> initcap
>> --------------
>> First.second
>> (1 row)
>> postgres=# SELECT initcap('first.second' COLLATE "en_US");
>> initcap
>> --------------
>> First.Second
>> (1 row)
>>
>> This behaviour is reproducible on REL_12_STABLE and up to master
>>
>> I don't believe that this is an erroneous behaviour, just a differing
>> one, hence
>> just a documentation change proposition
>>
>> I suggest adding a clarification that this function works differently
>> with libc
>> and ICU providers because there is a difference in what a "word" is
>> between them
>>
>> In libc a word is a sequence of alphanumeric characters, separated by
>> non-alphanumeric characters (as it is written in documentation right
>> now)
>> In ICU words are divided according to Unicode® Standard Annex #29 [1]
>>
>> Similar issue was briefly discussed in [2]
>>
>> The suggested documentation patch is attached (versions for
>> REL_13_STABLE+ and
>> for REL_12_STABLE only)
>>
>> [1]: https://www.unicode.org/reports/tr29/#Word_Boundaries
>> [2]:
>> https://www.postgresql.org/message-id/CAEwbS1R8pwhRkwRo3XsPt24ErBNtFWuReAZhVPJwA3oqo148tA%40mail.gmail.com
>>
>> Oleg Tselebrovskiy, Postgres
>> Professional<v1-0001-string-functions.patch><v1-0002-string-functions-REL_12.patch>
>>
>>
>> I can confirm inicap works with libc and libicu as you stated.  The
>> documentation patch looks good to me.  I’ve written a commit message.
>> The REL_12_STABLE branch is not relevant anymore as it’s out of
>> support.  I’m going to push this if no objections.
>
> I'm sorry for these many messages.  My email client just gone crazy.
> Must be fixed now.
>
> ------
> Regards,
> Alexander Korotkov
> Supabase

Commit message looks good to me, also no objections on ignoring
REL_12_STABLE :)
Thank you!

Regards, Oleg Tselebrovskiy