Andrew Gierth <and...@tao11.riddles.org.uk> writes:
> "Peter" == Peter Eisentraut <peter.eisentr...@enterprisedb.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
