On Thu, Sep 07, 2006 at 03:38:10PM +0100, Gregory Stark wrote:
> Well I for one would be pretty unhappy if ICU were integrated. It seems like a
> whole pile of code and complexity for no particular gain. The standard i18n
> support with a few extensions (namely strcoll_l) seems to be adequate for us
> and not introduce huge new dependencies and code burdens.
Let's be serious here. The patch is 18k (729 lines), hardly "whole pile
of code and complexity". The patch has been in the FreeBSD ports
collection for a rather long time, so it's not like it's not tested.
http://www.freebsd.org/cgi/cvsweb.cgi/ports/databases/postgresql81-server/Makefile?rev=1.156&content-type=text/x-cvsweb-markup
and search for "ICU". The actual patches are here:
http://people.freebsd.org/~girgen/postgresql-icu/
The point is that strcoll_l doesn't exist on most platforms, so unless
someone is going to write another locale library, why not just use one
that's available?
> That's why I mentioned pg_strxfrm. It doesn't solve all your problems if
> you're doing lots of string manipulations in queries but it can handle
> collation so you can at least execute ORDER BY clauses which of course you
> can't efficiently do in the client. For anything more complex you're probably
> happier doing your string manipulations in the client just because SQL's
> string primitives are so, well, primitive.
I think you're making the assumption that client locale support is
going to be better than the server's.
Besides, pg_strxfrm doesn't help you if you want to do
accent-insensetive matching. Sometimes you don't just want to change
the order, you also want to change what is equal.
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.