From: | Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> |
---|---|
To: | hannu(at)tm(dot)ee |
Cc: | tgl(at)sss(dot)pgh(dot)pa(dot)us, olly(at)lfix(dot)co(dot)uk, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Unicode upper() bug still present |
Date: | 2003-10-20 12:37:15 |
Message-ID: | 20031020.213715.74754803.t-ishii@sra.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> Tom Lane kirjutas E, 20.10.2003 kell 03:35:
> > Oliver Elphick <olly(at)lfix(dot)co(dot)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 ?
There's absolutely no relationship between database encoding and
locale. IMO depending on the system locale is a completely wrong
design decision and we should go toward for having our own collate
data. (I think Oracle does this way)
--
Tatsuo Ishii
From | Date | Subject | |
---|---|---|---|
Next Message | Hannu Krosing | 2003-10-20 12:42:45 | Re: Unicode upper() bug still present |
Previous Message | Paul Vernon | 2003-10-20 12:05:26 | Re: Dreaming About Redesigning SQL |