Re: Order changes in PG16 since ICU introduction
От | Tom Lane |
---|---|
Тема | Re: Order changes in PG16 since ICU introduction |
Дата | |
Msg-id | 3369718.1682100417@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Order changes in PG16 since ICU introduction (Andrew Gierth <andrew@tao11.riddles.org.uk>) |
Ответы |
Re: Order changes in PG16 since ICU introduction
|
Список | pgsql-hackers |
Andrew Gierth <andrew@tao11.riddles.org.uk> writes: > "Peter" == Peter Eisentraut <peter.eisentraut@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
В списке pgsql-hackers по дате отправления: