Jeff Davis wrote:
> New patch series attached. I plan to commit 0001 and 0002 soon, unless
> there are objections.
>
> 0001 causes the "C" and "POSIX" locales to be treated with
> memcmp/pg_ascii semantics in ICU, just like in libc. We also
> considered a new "none" provider, but it's more invasive, and we can
> always reconsider that in the v17 cycle.
FWIW I don't quite see how 0001 improve things or what problem it's
trying to solve.
0001 creates exceptions throughout the code so that when an ICU
collation has a locale name "C" or "POSIX" then it does not behave
like an ICU collation, even though pg_collation.collprovider='i'
To me it's neither desirable nor necessary that a collation that
has collprovider='i' is diverted to non-ICU semantics.
Also in the current state, this diversion does not apply to initdb.
"initdb --icu-locale=C" with 0001 applied reports this:
Using language tag "en-US-u-va-posix" for ICU locale "C".
The database cluster will be initialized with this locale configuration:
provider: icu
ICU locale: en-US-u-va-posix
LC_COLLATE: fr_FR.UTF-8
[...]
and "initdb --locale=C" reports this:
Using default ICU locale "fr_FR".
Using language tag "fr-FR" for ICU locale "fr_FR".
The database cluster will be initialized with this locale configuration:
provider: icu
ICU locale: fr-FR
LC_COLLATE: C
[...]
Could you elaborate a bit more on what 0001 is meant to achieve, from
the point of view of the user?
Best regards,
--
Daniel Vérité
https://postgresql.verite.pro/
Twitter: @DanielVerite