Skip site navigation (1) Skip section navigation (2)

Re: [GENERAL] trouble with to_char('L')

From: Hiroshi Inoue <inoue(at)tpf(dot)co(dot)jp>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [GENERAL] trouble with to_char('L')
Date: 2009-06-03 23:41:41
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-generalpgsql-hackers
Tom Lane wrote:
> Hiroshi Inoue <inoue(at)tpf(dot)co(dot)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.

HIroshi Inoue

In response to

pgsql-hackers by date

Next:From: Jeremy KerrDate: 2009-06-03 23:44:30
Subject: Re: [PATCH v2] Add bit operations util header
Previous:From: Andrew DunstanDate: 2009-06-03 23:40:54
Subject: Re: It's June 1; do you know where your release is?

pgsql-general by date

Next:From: Scott MarloweDate: 2009-06-04 00:54:19
Subject: Re: High I/O writes activity on disks causing images on browser to lag and not load
Previous:From: Jennifer TreyDate: 2009-06-03 22:34:07
Subject: Re: High I/O writes activity on disks causing images on browser to lag and not load

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group