From: | Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> |
---|---|
To: | peter_e(at)gmx(dot)net |
Cc: | pgsql-hackers(at)postgresql(dot)org, eutm(at)yandex(dot)ru |
Subject: | Re: Multibyte support in oracle_compat.c |
Date: | 2002-09-05 01:09:06 |
Message-ID: | 20020905.100906.57440898.t-ishii@sra.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> 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
> encoding choice is database-specific (in other words: it's broken), but
> there's nothing we can do about that right now.
I thought his idea was using UTF-8 locale and Unicode (UTF-8) encoded
database.
> Btw., I just happened to think about this very issue over the last few
> days. What I would like to attack for the next release is to implement
> character classification and conversion using the Unicode tables so we can
> cut the LC_CTYPE system locale out of the picture. Perhaps this is what
> the poster was thinking of, too.
Interesting idea. If you are saying that you are going to remove the
dependecy on system locale, I will agree with your idea.
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.
--
Tatsuo Ishii
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2002-09-05 01:46:36 | Re: Schemas not available for pl/pgsql %TYPE.... |
Previous Message | Tom Lane | 2002-09-05 01:01:38 | Re: Open pg_dump issues |