Re: Unicode upper() bug still present

Поиск
Список
Период
Сортировка
От Hannu Krosing
Тема Re: Unicode upper() bug still present
Дата
Msg-id 1066634549.15789.20.camel@fuji.krosing.net
обсуждение исходный текст
Ответ на Re: Unicode upper() bug still present  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Unicode upper() bug still present  (Tatsuo Ishii <t-ishii@sra.co.jp>)
Re: Unicode upper() bug still present  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Tom Lane kirjutas E, 20.10.2003 kell 03:35:
> Oliver Elphick <olly@lfix.co.uk> writes:
> > There is a bug in Unicode upper() which has been present since 7.2:
>
> We don't support upper/lower in multibyte character sets, and can't as
> long as the functionality is dependent on <ctype.h>'s toupper()/tolower().
> It's been suggested that we could use <wctype.h> where available.
> However there are a bunch of issues that would have to be solved to make
> that happen.  (How do we convert between the database character encoding
> and the wctype representation?

How do we do it for sorting ?

> How do we even find out what
> representation the current locale setting expects to use?)

Why not use the same locale settings as for sorting (i.e. databse
encoding) until we have a proper multi-locale support in the backend ?

It seems inconsistent that we do use locale-aware sorts but not
upper/lower.

this is for UNICODE database using locale et_EE.UTF-8

ucdb=# select t, upper(t) from tt order by 1;t | upper
---+-------a | As | SŠ | Šš | šÕ | Õõ | õÄ | Ää | ä
(8 rows)

as you see, the sort order is right, but "some" characters are and some
are not converted the result is a complete mess ;(

-------------------
Hannu



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

Предыдущее
От: Sailesh Krishnamurthy
Дата:
Сообщение: Re: Dreaming About Redesigning SQL
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: A couple of TODO notes