> GNU gettext does its own encoding conversion. It reads the program's
> character encoding from the LC_CTYPE locale and converts the material in
> the translation catalogs on the fly for output. This is great in general,
> really, but for the postmaster it's a problem. If LC_CTYPE is fixed for
Tatsuo Ishii writes:
> BTW, nls has same problem as above, no? I guess nls depeneds on locale
> and it may conflict with the database-specific encoding and/or the
> automatic FE/BE encoding conversion.
GNU gettext does its own encoding conversion. It reads the program's
character encoding from
> The backend routines use the host OS locales, so look there. On my
> machine I have several Russian locales, which seem to address the issue of
> character sets:
>
> ru_RU
> ru_RU.koi8r
> ru_RU.utf8
> ru_UA
> russian
>
> This is bogus, because the LC_CTYPE choice is cluster-wide and the
> enc
On Thu, 5 Sep 2002, Peter Eisentraut wrote:
> Date: Thu, 5 Sep 2002 00:46:39 +0200 (CEST)
> From: Peter Eisentraut <[EMAIL PROTECTED]>
> To: Tatsuo Ishii <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
> Subject: Re: [HACKERS] Multibyte support in
Tatsuo Ishii writes:
> > Functions upper,lower and initcap doesn't work with utf-8 data
The backend routines use the host OS locales, so look there. On my
machine I have several Russian locales, which seem to address the issue of
character sets:
ru_RU
ru_RU.koi8r
ru_RU.utf8
ru_UA
russian
> I found one bug in file src/backend/utils/adt/oracle_compat.c and there were
>your name, related with Multibyte enhancement, so i write to you.
> Functions upper,lower and initcap doesn't work with utf-8 data which is not of
>Latin letters.At my work i do databases for Russian users an
