From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> |
Cc: | pgsql-hackers(at)postgresql(dot)org, <eutm(at)yandex(dot)ru> |
Subject: | Re: Multibyte support in oracle_compat.c |
Date: | 2002-09-04 22:46:39 |
Message-ID: | Pine.LNX.4.44.0209042041360.1333-100000@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
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.
> > P.S.It doesn't seem bad for me to use lib unicode instead of functions like mbtowc,wctomb from stdlib and towupper,towlower from wctype
>
> I'm not sure. What do you think, Peter or other guys who is familiar
> with Unicode?
I don't know that that libunicode is, but that shouldn't prevent us from
possibly evaluating it. :-)
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.
--
Peter Eisentraut peter_e(at)gmx(dot)net
From | Date | Subject | |
---|---|---|---|
Next Message | Serguei Mokhov | 2002-09-04 22:51:03 | Re: fix for palloc() of user-supplied length |
Previous Message | Serguei Mokhov | 2002-09-04 22:37:44 | Re: fix for palloc() of user-supplied length |