Re: [GENERAL] trouble with to_char('L')
От | Hiroshi Inoue |
---|---|
Тема | Re: [GENERAL] trouble with to_char('L') |
Дата | |
Msg-id | 4A270A35.3020705@tpf.co.jp обсуждение исходный текст |
Ответ на | Re: [GENERAL] trouble with to_char('L') (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: