Re: Unicode upper() bug still present

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

In response to

Responses

Browse pgsql-hackers by date

  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