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