Re: Multibyte support in oracle_compat.c

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: Multibyte support in oracle_compat.c
Дата
Msg-id Pine.LNX.4.44.0209042041360.1333-100000@localhost.localdomain
обсуждение исходный текст
Ответ на Re: Multibyte support in oracle_compat.c  (Tatsuo Ishii <t-ishii@sra.co.jp>)
Ответы Re: Multibyte support in oracle_compat.c  ("Serguei A. Mokhov" <sa_mokho@alcor.concordia.ca>)
Re: Multibyte support in oracle_compat.c  (Tatsuo Ishii <t-ishii@sra.co.jp>)
Список 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,towlowerfrom 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@gmx.net



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Neil Conway
Дата:
Сообщение: Re: Beta1 schedule
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Open pg_dump issues