Re: Order changes in PG16 since ICU introduction
От | Tatsuo Ishii |
---|---|
Тема | Re: Order changes in PG16 since ICU introduction |
Дата | |
Msg-id | 20230608.093033.648172765268838567.t-ishii@sranhm.sra.co.jp обсуждение исходный текст |
Ответ на | Re: Order changes in PG16 since ICU introduction (Jeff Davis <pgsql@j-davis.com>) |
Ответы |
Re: Order changes in PG16 since ICU introduction
Re: Order changes in PG16 since ICU introduction |
Список | pgsql-hackers |
Hi, > On Wed, 2023-06-07 at 23:50 +0200, Daniel Verite wrote: >> The simplest way to obtain that in v16 is to teach initdb that >> --locale=C without the --locale-provider option implies that >> --locale-provider=libc ([1]) > > As I replied in that subthread, that creates a worse problem: if you > only change the provider when the locale is C, then what about when the > locale is *not* C? > > export LANG=en_US.UTF-8 > initdb -D data --locale=fr_FR.UTF-8 > ... > provider: icu > ICU locale: en-US > > I believe that case is an order of magnitude worse than the other cases > you brought up in that subthread. > > It also leaves the fundamental problem in place that LOCALE only > applies to the libc provider, which multiple people have agreed is not > acceptable. Daniels comment: >> Yes it's a special case but when doing initdb --locale=C, a user does >> not need or want an ICU locale. They want the same thing than what v15 >> does with the same arguments: a template0 database with >> datlocprovider='c', datcollate='C', datctype='C', dateiculocale=NULL. So in this case the only way to keep the same behavior in v16 with "initdb --locale=C" (--no-locale) in v15 is, bulding PostgreSQL --without-icu? Best reagards, -- Tatsuo Ishii SRA OSS LLC English: http://www.sraoss.co.jp/index_en/ Japanese:http://www.sraoss.co.jp
В списке pgsql-hackers по дате отправления: