Re: [BUGS] Bug #659: lower()/upper() bug on ->multibyte<- DB

Поиск
Список
Период
Сортировка
От Tatsuo Ishii
Тема Re: [BUGS] Bug #659: lower()/upper() bug on ->multibyte<- DB
Дата
Msg-id 20020511103653N.t-ishii@sra.co.jp
обсуждение исходный текст
Список pgsql-hackers
[Cc:ed to hackers]

(trying select convert(lower(convert('X', 'LATIN1')),'LATIN1','UNICODE');)

> Ok, this is working now (I cann't reproduce why not at the first time).

Good.

> Is it planned to implement it so that I can write lower()/ upper() for multibyte
> according to SQL standard (without convert)?

SQL standard? The SQL standard says nothing about locale. So making
lower() (and others) "locale aware" is far different from the SQL
standard of point of view. Of course this does not mean "locale
support" is should not be a part of PostgreSQL's implementation of
SQL. However, we should be aware the limitation of "locale support"
(as well as multibyte support). They are just the stopgap util CREATE
CHARACTER SET etc. is implemnted IMO.

> I could do it if you tell me where the final tolower()/toupper() happens.
> (but not before middle of June).

For the short term solution making convert() hiding from users might
be a good idea (what I mean here is kind of auto execution of
convert()). The hardest part is there's no idea how we could find a
relationship bewteen particular locale and the encoding. For example,
you know that for de_DE locale using LATIN1 encoding is appropreate,
but PostgreSQL does not.
--
Tatsuo Ishii


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

Предыдущее
От: Hiroshi Inoue
Дата:
Сообщение: Re: Queries using rules show no rows modified?
Следующее
От: Joe Conway
Дата:
Сообщение: Re: troubleshooting pointers