Peter Eisentraut <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
