Re: Multibyte support in oracle_compat.c
От | Tatsuo Ishii |
---|---|
Тема | Re: Multibyte support in oracle_compat.c |
Дата | |
Msg-id | 20020905.100906.57440898.t-ishii@sra.co.jp обсуждение исходный текст |
Ответ на | Re: Multibyte support in oracle_compat.c (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: Multibyte support in oracle_compat.c
|
Список | 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
В списке pgsql-hackers по дате отправления: