On Mon, Mar 28, 2016 at 10:24 AM, Tom Lane <tgl@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.
agree.
In other thread I wrote: "Ideally, we should benchmarking all locales on all platforms for all kind indexes. But that's big project."