Re: Fixed length data types issue - Mailing list pgsql-hackers

From Gregory Stark
Subject Re: Fixed length data types issue
Date
Msg-id 8764fzz97j.fsf@stark.xeocode.com
Whole thread Raw
In response to Re: Fixed length data types issue  (Martijn van Oosterhout <kleptog@svana.org>)
Responses Re: Fixed length data types issue  (Martijn van Oosterhout <kleptog@svana.org>)
List pgsql-hackers
Martijn van Oosterhout <kleptog@svana.org> writes:

> 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.

Uhm, an ICU source tree is over 40 *megabytes*. That's almost as much as the
rest of Postgres itself and that doesn't even include documentation. Even if
you exclude the data and regression tests you're still talking about depending
on the portability and correctness of over 10 megabytes of new code.

> 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?

Neither is ICU available on most platforms. In any case we only need strcoll_l
as a performance optimization, the regular interface works, it's just slow.

> I think you're making the assumption that client locale support is
> going to be better than the server's.

Well we know it is because Postgres's support is basically nonexistent.

> 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.

Well equal is part of collation at least in the sense you mean. What it
doesn't help with is things like tolower or regexp matching. These are the
things that I would suggest you usually want to be doing on the client because
SQL's string manipulation facilities are so poor compared to most client
languages.

-- 
greg



pgsql-hackers by date:

Previous
From: "Jim C. Nasby"
Date:
Subject: Re: Postgres tracking - the pgtrack project
Next
From: Gregory Stark
Date:
Subject: Re: Fixed length data types issue