Tom Lane <tgl@sss.pgh.pa.us> writes:
> Greg Stark <gsstark@mit.edu> writes:
> > But then I thought of another idea. What if Postgres just used strxfrm()
> > instead of strcoll everywhere? Then it ought to never produce inconsistent
> > results. At least if strxfrm() doesn't just return randomly varying results
> > for the same inputs.
>
> AFAICS the most that could accomplish is to make failures more obvious;
> it wouldn't actually fix anything. I don't think that's worth the
> runtime penalty it would incur.
What runtime penalty? It seems likely that strcoll is implemented by the
equivalent of calling strxfrm twice internally anyways. I don't see how that
could produce inconsistent results unless the internal interface has some
error handling codepath that returns an error that isn't being checked.
In fact calling strxfrm() has the potential to open up some optimizations.
Like caching the transformed string for the duration of a single sort
operation instead of repeatedly transforming it.
> What we *ought* to be doing is trying to figure a way to detect and
> disallow inconsistent locale/encoding combinations. We've avoided that
> because there seems no general platform-independent way to find out the
> encoding expected by a locale. But surely we could manage to make it
> work at least on glibc and Windows, which would be a step ahead of doing
> nothing.
Harumph. When I suggested having a strxfrm() function like the ones three
different people have independently developed and posted that would work
though slowly on all platforms, used only standard libc functions and perform
fine on at least glibc you complained it wasn't portable enough.
--
greg
