On Fri, Sep 08, 2006 at 10:35:58AM -0400, Tom Lane wrote:
> The reason this is a relevant consideration: we are talking about
> changes that would remove existing functionality for people who don't
> have that library.
Huh? If you don't select ICU at compile time you get no difference from
what we have now. I'm not sure I'm seeing your point. My COLLATE
patches did allow both to coexist, but no-one appeared to like that
idea either.
> I suppose it might be possible to do
> #ifdef HAVE_ICU
> ... new code ...
> #else
> ... existing code ...
> #endif
> but given the differences in API I can't believe this would be readable
> or maintainable.
That's what the patch does. And the api differences are marginal. They
even have C compatability functions to make it easier.
> Another problem is that AFAICT, depending on ICU would force us to
> standardize on Unicode as the *only* server internal encoding;
Huh? You can use whatever encoding you like... Actual collations are
determined on the basis of unicode properties, but I don't think that
is what you're referring to.
> what's more, the docs suggest that it doesn't support anything wider
> than UTF16.
Well, that's not true, which part of the docs were you looking at?
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.
