Re: [COMMITTERS] pgsql: Explicitly bind gettext() to the UTF8 locale when in use.
От | Magnus Hagander |
---|---|
Тема | Re: [COMMITTERS] pgsql: Explicitly bind gettext() to the UTF8 locale when in use. |
Дата | |
Msg-id | 492AB5AC.7060709@hagander.net обсуждение исходный текст |
Ответ на | Re: [COMMITTERS] pgsql: Explicitly bind gettext() to the UTF8 locale when in use. (Hiroshi Inoue <inoue@tpf.co.jp>) |
Ответы |
Re: Re: [COMMITTERS] pgsql: Explicitly bind gettext() to the UTF8 locale when in use.
|
Список | 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
В списке pgsql-hackers по дате отправления: