Re: Order changes in PG16 since ICU introduction

Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> writes:
> "Peter" == Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> writes:
> Peter> If the database is created with locale provider ICU, then
> Peter> lc_collate does not apply here,

> Having lc_collate return a value which is silently being ignored seems
> to me rather hugely confusing.

It's not *completely* ignored --- there are bits of code that are not
yet ICU-ified and will still use the libc facilities. So we can't
get rid of those options yet, even in an ICU-based database.

> Also, somewhere along the line someone broke initdb --no-locale, which
> should result in C locale being the default everywhere, but when I just
> tested it it picked 'en' for an ICU locale, which is not the right
> thing.

Confirmed:

$ LANG=en_US.utf8 initdb --no-locale
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.

Using default ICU locale "en_US".
Using language tag "en-US" for ICU locale "en_US".
The database cluster will be initialized with this locale configuration:
provider: icu
ICU locale: en-US
LC_COLLATE: C
LC_CTYPE: C
...

That needs to be fixed: --no-locale should prevent any consideration
of initdb's LANG/LC_foo environment.

regards, tom lane