Re: Re: [COMMITTERS] pgsql: Explicitly bind gettext() to the UTF8 locale when in use.
От | Magnus Hagander |
---|---|
Тема | Re: Re: [COMMITTERS] pgsql: Explicitly bind gettext() to the UTF8 locale when in use. |
Дата | |
Msg-id | 493659E1.2080207@hagander.net обсуждение исходный текст |
Ответ на | Re: 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: >> I think the thing us that as long as the encodings are compatible >> (latin1 with different names for example) it worked fine. >> >>> In any case I think the problem is that gettext is >>> looking at a setting that is not what we are looking at. Particularly >>> with the 8.4 changes to allow per-database locale settings, this has >>> got to be fixed in a bulletproof way. > > Attached is a new patch to apply bind_textdomain_codeset() to most > server encodings. Exceptions are PG_SQL_ASCII, PG_MULE_INTERNAL > and PG_EUC_JIS_2004. "EUC-JP" may be OK for EUC_JIS_2004. > > Unfortunately it's hard for Saito-san and me to check encodings > other than EUC-JP. In principle this looks good, I think, but I'm a bit worried around the lack of testing. I can do some testing under LATIN1 which is what we use in Sweden (just need to get gettext working *at all* in my dev environment again - I've somehow managed to break it), and perhaps we can find someone to do a test in an eastern-european locale to get some more datapoints? Can you outline the steps one needs to go through to show the problem, so we can confirm it's fixed in these locales? //Magnus
В списке pgsql-hackers по дате отправления: