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

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Hiroshi Inoue <inoue(at)tpf(dot)co(dot)jp>
Cc: PG Hackers <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Hiroshi Saito <z-saito(at)guitar(dot)ocn(dot)ne(dot)jp>
Subject: Re: [COMMITTERS] pgsql: Explicitly bind gettext() to the UTF8 locale when in use.
Date: 2008-11-24 14:09:48
Message-ID: 492AB5AC.7060709@hagander.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

Hiroshi Inoue wrote:
> Magnus Hagander wrote:
>> Hiroshi Inoue wrote:
>>> Hi Magnus and all,
>>>
>>> Magnus Hagander wrote:
>>>> Log Message:
>>>> -----------
>>>> Explicitly bind gettext() to the UTF8 locale when in use.
>>>> This is required on Windows due to the special locale
>>>> handling for UTF8 that doesn't change the full environment.
>>> Thanks to this change UTF-8 case was solved but Japanese users
>>> are still unhappy with Windows databases with EUC_JP encoding.
>>> Shift_JIS which is a Japanese encoding under Windows doesn't
>>> match any server encoding and causes a crash with the use of
>>> gettext. So Saito-san removed ja message catalog just before
>>> the 8.3 release.
>>>
>>> Attached is a simple patch to avoid the crash and enable the
>>> use of Japanese message catalog.
>>> Please apply the patch if there's no problem.
>> Hi!
>>
>> It will clearly also need an update to the comment, but I can take care
>> of that.
>>
>> I assume you have tested this?
>
> Though I myself didn't test it, Saito-san tested it.

Ok, good.

>> The comment says that it works because we
>> are handling UTF8 on a special way on Windows,
>
> ISTM UTF-8 isn't a special case.
> In fact the comment also mentions the following.
>
> * In future we might want to call bind_textdomain_codeset
> * unconditionally, but that....

I think that's partially unrelated. UTF8 is special in that the
environment that the backend runs in is different from SERVER_ENCODING
in this case. For other encodings, we have setlocale():d to the same
encoding.

>> If your database is in EUC_JP, I don't see why gettext() isn't picking
>> it up properly in the first place..
>
> In Japan 2 encodings (EUC_JP and Shift_JIS) are often used.
> EUC_JP is mainly used on *nix and on Windows Shift_JIS is
> used. We use EUC_JP not Shift_JIS as the server encoding
>
>> And why do we need that on Windows only, and not on other platforms?
>
> 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?

Ok, I think I understand. I've made some minor stylistic changes (we
don't normally use if (NULL != <whatever>) in the pg sources), and will
apply with those.

This is for HEAD only, correct? Or is it something we should backpatch?

//Magnus

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Peter Eisentraut 2008-11-24 14:40:00 Re: [COMMITTERS] pgsql: Add support for matching wildcard server certificates to the new
Previous Message User Fxjr 2008-11-24 14:01:24 npgsql - Npgsql2: Fixed problem where parameters size wasn't being

Browse pgsql-hackers by date

  From Date Subject
Next Message Dave Page 2008-11-24 14:10:29 Re: blatantly a bug in the documentation
Previous Message Dave Page 2008-11-24 14:07:49 Re: blatantly a bug in the documentation