Tom Lane wrote: > Hiroshi Inoue <in...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
