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