From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Hannu Krosing <hannu(at)tm(dot)ee> |
Cc: | Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>, olly(at)lfix(dot)co(dot)uk, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Unicode upper() bug still present |
Date: | 2003-10-20 13:18:54 |
Message-ID: | 1886.1066655934@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hannu Krosing <hannu(at)tm(dot)ee> writes:
> Tatsuo Ishii kirjutas E, 20.10.2003 kell 15:37:
>> There's absolutely no relationship between database encoding and
>> locale.
> How does the system then use locale for sorting and not for upper/lower
> ?
LC_COLLATE and LC_CTYPE are independent settings. But in any case
Tatsuo is correct about the long-term direction we need to take ---
in order to come anywhere near SQL-standard behavior, we have to support
multiple locales simultaneously, and that means that the standard C
library's API isn't gonna do it.
>> IMO depending on the system locale is a completely wrong
>> design decision and we should go toward for having our own collate
>> data.
I noticed by chance that glibc has a "reentrant locale" API that seems
to allow for efficient access to multiple locales concurrently. Perhaps
it would be a reasonable solution to support multiple locales only on
machines that have this library. If we have to write our own locale
support it's likely to be a long time coming :-(
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jeroen T. Vermeulen | 2003-10-20 13:35:43 | In-doubt window |
Previous Message | Tom Lane | 2003-10-20 13:05:48 | Re: Unicode upper() bug still present |