Re: Unicode upper() bug still present

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Hannu Krosing <hannu(at)tm(dot)ee>, 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 19:37:28
Message-ID: 12466.1066678648@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Tom Lane writes:
>> If we have to write our own locale
>> support it's likely to be a long time coming :-(

> Naturally, I cannot promise anything, but this is at the top of my list
> for the next release. I already have sorted out the specifications and
> algorithms and collected locale data for most corners of the world, so
> it's just the coding left. Unfortunately, a real, sustainable fix of this
> situations requires us to start at the very bottom,

I'm not sure that "supporting our own locale subsystem" really qualifies
as "sustainable" ... can you give an estimate of how big the code +
supporting data is likely to be?

(Perhaps the size of the corresponding parts of glibc would do as an
estimate --- I don't know that offhand, but surely we could find it
out.)

I agree that depending on the system-provided locale behavior has its
downsides, but it has its upsides too; compatibility with the behavior
of everything else on the machine being one big one. So the idea of
being able to use glibc where available shouldn't be rejected out of
hand, I think.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2003-10-20 19:39:31 Re: In-doubt window
Previous Message Tom Lane 2003-10-20 19:30:26 Re: Unicode upper() bug still present