Tom Lane wrote:
> Hiroshi Inoue <inoue@tpf.co.jp> writes:
>> Tom Lane wrote:
>>> * This seems to be assuming that the user has set LC_MONETARY and
>>> LC_NUMERIC the same. What if they're different?
>
>> Strictky speaking they should be handled individually.
>
> I thought about this some more, and I wonder why you did it like this at
> all. The patch claimed to be copying the LC_TIME code, but the LC_TIME
> code isn't trying to temporarily change any locale settings.
LC_TIME and LC_CTYPE (on Windows) settings are changed temporarily
in cache_locale_time() in pg_locale.c.
> What we
> are doing in that code is assuming that the system will give us back
> the localized strings in the encoding identified by CP_ACP;
AFAIK it's not right. LC_TIME, LC_MONETARY or LC_NUMERIC related output
is encoded using LC_CTYPE setting.
> so all we
> have to do is convert CP_ACP to wide chars and then to UTF8. Can't we
> use a similar approach for the output of localeconv?
What LC_CTIME code and my patch intend is setting LC_CTYPE to an
appropriate value so that related output is converted correctly.
If we can set LC_CTYPE to xxx_xxx.65001(UTF8), we can eliminate
two steps but it causes an error on Windows.
regards,
HIroshi Inoue
