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
Can you outline the steps one needs to go through to show the problem,
so we can confirm it's fixed in these locales?
In response to
pgsql-hackers by date
|Next:||From: Guillaume Smet||Date: 2008-12-03 10:09:17|
|Subject: Re: maintenance memory vs autovac|
|Previous:||From: Greg Stark||Date: 2008-12-03 09:49:32|
|Subject: Re: Erroring out on parser conflicts|
pgsql-committers by date
|Next:||From: User Mkz||Date: 2008-12-03 11:02:21|
|Subject: pgbouncer - pgbouncer: win32: change name of eventmsg|
|Previous:||From: Heikki Linnakangas||Date: 2008-12-03 08:20:13|
|Subject: pgsql: If pg_stop_backup() is called just after switching to a new xlog |