Re: Draft release notes for next week's releases

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Oleg Bartunov <obartunov(at)gmail(dot)com>, Peter Geoghegan <pg(at)heroku(dot)com>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Draft release notes for next week's releases
Date: 2016-03-28 15:08:05
Message-ID: CA+TgmoZDQrhC6QapG8w+jYq22W8kXY+ii4=7x9Yy2pY0Sq8Qbw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Mar 28, 2016 at 10:24 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2016-03-28 15:38:43 Re: Move PinBuffer and UnpinBuffer to atomics
Previous Message Stephen Frost 2016-03-28 14:57:04 Dealing with collation and strcoll/strxfrm/etc