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
Re: Multibyte support in oracle_compat.c |
Список | 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 по дате отправления: