On Mon, 2025-11-03 at 20:14 +0100, Daniel Verite wrote:
> No, I think we should put the database's lc_ctype
> into LC_CTYPE and the database's lc_collate into
> LC_COLLATE, independently of anything else,
> like it was done until commit 5e6e42e.
> I believe that's the purpose of these database
> properties, whether the provider is libc or ICU or builtin.
Is there a clean way to document this behavior? I have tried to improve
the documentation in this area before, but it's not easy because the
behavior is so nuanced.
The CREATE DATABASE command needs LOCALE (or LC_CTYPE/LC_COLLATE). But
it's easy to get LOCALE and ICU_LOCALE or BUILTIN_LOCALE confused. And
similarly for initdb. We could clean those up a lot if
LC_CTYPE/LC_COLLATE didn't even need to be set for non-libc providers.
Users can end up in a situation where they need to define
LC_CTYPE/LC_COLLATE, even though it has almost (but not entirely) no
effect:
https://www.postgresql.org/message-id/f794e177b0b1ed8917e75258726ae315cf8fbbef.camel%40j-davis.com
Reverting commit 5e6e42e may be the right thing, but I'd like to hear
what others have to say on this point first. In particualr, I'd like to
know whether such a revert is based on principle, a practical problem,
or just an abundance of caution.
Another option we have here is LC_CTYPE=LC_COLLATE=C for non-libc
providers, but leave it as in v17 for libc providers. If someone
explicitly wants libc behavior (by specifying something like "use
locale" in plperl), they probably want to be using the libc provider
for the database.
Regards,
Jeff Davis
