Jeff Davis wrote:
> I implemented a compromise where initdb will
> change C.UTF-8 to the built-in provider
This handling of C.UTF-8 would be felt by users as simply broken.
With the v10 patches:
$ initdb --locale=C.UTF-8
initdb: using locale provider "builtin" for ICU locale "C.UTF-8"
The database cluster will be initialized with this locale configuration:
default collation provider: builtin
default collation locale: C
LC_COLLATE: C.UTF-8
LC_CTYPE: C.UTF-8
This setup is not what the user has asked for and leads to that kind of
wrong results:
$ psql -c "select upper('é')"
?column?
----------
é
whereas in v15 we would get the correct result 'É'.
Then once inside that cluster, trying to create a database:
postgres=# create database test locale='C.UTF-8';
ERROR: locale provider "builtin" does not support locale "C.UTF-8"
HINT: The built-in locale provider only supports the "C" and "POSIX"
locales.
That hardly makes sense considering that initdb stated the opposite,
that the "built-in provider" was adequate for C.UTF-8
In general about the evolution of the patchset, your interpretation
of "defaulting to ICU" seems to be "avoid libc at any cost", which IMV
is unreasonably user-hostile.
Best regards,
--
Daniel Vérité
https://postgresql.verite.pro/
Twitter: @DanielVerite
