From: | Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp> |
---|---|
To: | pgsql(at)j-davis(dot)com, daniel(at)manitou-mail(dot)org, peter(dot)eisentraut(at)enterprisedb(dot)com, andrew(at)tao11(dot)riddles(dot)org(dot)uk, tgl(at)sss(dot)pgh(dot)pa(dot)us, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Order changes in PG16 since ICU introduction |
Date: | 2023-06-08 01:45:35 |
Message-ID: | 20230608.104535.2171011311090815110.t-ishii@sranhm.sra.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>> 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.
Note that most of PostgreSQL users in Japan do initdb
--no-locale. Almost never use other than C locale because the users do
not rely on system collation. Most database have an extra column which
represents the pronunciation in Hiragana or Katakana.
Best reagards,
--
Tatsuo Ishii
SRA OSS LLC
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiro Ikeda | 2023-06-08 01:57:55 | Re: Introduce WAIT_EVENT_EXTENSION and WAIT_EVENT_BUFFER_PIN |
Previous Message | Noah Misch | 2023-06-08 01:45:07 | Re: win32ver data in meson-built postgres.exe |