Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > initdb -E UTF8 --locale=Japanese_Japan.932 -- CP932 is SJIS in nature
>
> Hmm, but does that really work safely? I think varstr_cmp() does work,
> because it forces our data into wchar format and then calls wcscoll().
> The thing that scares me is that various random other operating-system
> calls might deliver strings in an unexpected encoding. We've been
> through similar problems with timezone names reported by strftime, for
> example.
Hmm, I see we might need to replace all locale-aware functions to
wchar_t versions, for example, wcsftime instead of strftime.
It requires more tests. It should be saved for 8.4.
The attached is the second plan. It uses UTF-8 and locale=C when
the default locale encoding is not supported and none of encoding and
locale are passed to initdb. It would help users who use the default
settings (including regression test).
At the moment, it reset all of lc_* variables, but it might be possible
use the default locale at lc_messages, lc_monetary, lc_numeric and lc_time
even if lc_collate and lc_ctype are reset to C.
Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center