On Mon, Mar 28, 2016 at 6:08 PM, Robert Haas <robertmh...@gmail.com> wrote:

> On Mon, Mar 28, 2016 at 10:24 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> > I'm also not exactly convinced by your implicit assumption that ICU is
> > bug-free.

> Noah spent some time looking at ICU back when he was EnterpriseDB, and
> his conclusion was that ICU collations weren't stable across releases,
> which is pretty much the same problem we're running into with glibc
> collations.  Now it might still be true that they have the equivalent
> of strxfrm() and strcoll() and that those things behave consistently
> with each other, and that would be very good.  Everybody seems to
> agree it's faster, and that's good, too.  But I wonder what we do
> about the fact that, as with glibc, an ICU upgrade involves a REINDEX
> of every potentially affected index.  It seems like ICU has some
> facilities built into it that might be useful for detecting and
> handling such situations, but I don't understand them well enough to
> know whether they'd solve our versioning problems or how effectively
> they would do so, and I think there are packaging issues that tie into
> it, too.  http://userguide.icu-project.org/design mentions building
> with specific configure flags if you need to link with multiple server
> versions, and I don't know what operating system packagers typically
> do about that stuff.
> In any case, I agree that we'd be very unwise to think that ICU is
> necessarily going to be bug-free without testing it carefully.


In other thread I wrote:
"Ideally, we should benchmarking all locales on all platforms for all kind
indexes. But that's  big project."

> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company

Reply via email to