MIME-Version: 1.0
Date: Tue, 29 Jul 2025 11:03:33 +0700
From: Oleg Tselebrovskiy <o.tselebrovskiy@postgrespro.ru>
To: Alexander Korotkov <aekorotkov@gmail.com>
Cc: pgsql-docs@lists.postgresql.org
Subject: Re: Initcap works differently with different locale providers
In-Reply-To: 
 <CAPpHfdvsYKYG2PnhxEha=aE+Mtj=+peFbRah_K4A60aYsqFbrg@mail.gmail.com>
References: <804cc10ef95d4d3b298e76b181fd9437@postgrespro.ru>
 <0658C8F0-5ED4-4962-A2A3-524B0D899982@gmail.com>
 <CAPpHfdvsYKYG2PnhxEha=aE+Mtj=+peFbRah_K4A60aYsqFbrg@mail.gmail.com>
Message-ID: <0a54a90a5154281486b1acb07e5650df@postgrespro.ru>
Organization: Postgres Pro
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/0a54a90a5154281486b1acb07e5650df%40postgrespro.ru>
Precedence: bulk

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

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

Regards, Oleg Tselebrovskiy