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

From Tatsuo Ishii
Subject Re: [BUGS] Bug #659: lower()/upper() bug on ->multibyte<- DB
Date
Msg-id 20020511103653N.t-ishii@sra.co.jp
Whole thread Raw
List 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 by date:

Previous
From: Hiroshi Inoue
Date:
Subject: Re: Queries using rules show no rows modified?
Next
From: Joe Conway
Date:
Subject: Re: troubleshooting pointers