Re: Re: [COMMITTERS] pgsql: Explicitly bind gettext() to the UTF8 locale when in use. - Mailing list pgsql-hackers

From Hiroshi Inoue
Subject Re: Re: [COMMITTERS] pgsql: Explicitly bind gettext() to the UTF8 locale when in use.
Date
Msg-id 492B6A55.6010308@tpf.co.jp
Whole thread Raw
In response to Re: Re: [COMMITTERS] pgsql: Explicitly bind gettext() to the UTF8 locale when in use.  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Re: [COMMITTERS] pgsql: Explicitly bind gettext() to the UTF8 locale when in use.
List pgsql-hackers
Tom Lane wrote:
> Magnus Hagander <magnus@hagander.net> writes:
>> Hiroshi Inoue wrote:
>>> because Shift_JIS isn't allowed as a server encoding. So
>>> the Japanese Windows native message encoding Shift_JIS never
>>> matches the server encoding EUC_JP and a conversion between
>>> Shitt_jis and EUC_JP is necessarily needed.
> 
>> Ah, so we're basically hardcoding that information? The system will go
>> up in SJIS, but since we can't deal with it, we switch it to EUC_JP?
> 
> I'm not following this either.  If the patch is really necessary then it
> seems it must be working around a bug in the Windows version of gettext,
> ie failure to distinguish CP932 from CP20932.  Is that correct?

I'm afraid I don't understand what you mean exactly.
AFAIK the output encoding of Windows gettext is detemined by the
ANSI system code page which is usualy CP932(Shift_JIS) in Japan andunrelated to the locale settings.
In addition CP20932 is rarely used in Japan IIRC. I've never used it
and don't know what it is correctly (maybe a kind of EUC_JP).

regards,
Hiroshi Inoue



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: huge query tree cost too much time to copyObject()
Next
From: Tom Lane
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Explicitly bind gettext() to the UTF8 locale when in use.