Re: Collation versioning

From: Greg Stark <stark(at)mit(dot)edu>
To: Douglas Doole <dougdoole(at)gmail(dot)com>
Cc: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Christoph Berg <myon(at)debian(dot)org>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Collation versioning
Date: 2018-09-17 19:32:16
Message-ID: CAM-w4HNwnf9VGRaQgeAvuAupDBQQQEbJUXUxeU7wV_E9PjtaSw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon 17 Sep 2018, 13:02 Douglas Doole, <dougdoole(at)gmail(dot)com> wrote:

> On Sun, Sep 16, 2018 at 1:14 PM Thomas Munro <
> thomas(dot)munro(at)enterprisedb(dot)com> wrote:
>
>> We have to start somewhere and indexes are the first thing that people
>> notice, and are much likely to actually be a problem (personally I've
>> encountered many cases of index corruption due to collation changes in
>> the wild, but never a constraint corruption,
>
>
> Problems that people notice are good - it's the ones that they don't
> notice that cause real grief ;-)
> ...
>
> Once you get into downstream effects of changes (whether they are
>>
> recorded in the database or elsewhere), I think it's basically beyond
>> our event horizon.
>
> ...
>
>> I think we should make a clear distinction between
>> things that invalidate the correct working of the database, and more
>> nebulous effects that we can't possibly track in general.
>>
>
> I agree that PostgreSQL can't resolve the downstream changes, but that's a
> very subtle distinction. As a user, if an upgrade caused my data to no
> longer comply with my carefully architected and database enforced BI rules,
> I would definitely argue that the correct working of the database has been
> invalidated. (You can make technical arguments about the OS upgrading the
> library, but the fundamental issue is that my PostgreSQL database is
> broken.)
>

Well things like partition exclusion and even join elimination depend on
constraints being consistent so I don't think it's as easy to write off as
that either.

But it's true that we have to start somewhere and collation changes are
much more likely to be spotted in indexes and cause much more visible
issues.

> You can probably argue that PostgreSQL and DB2 users look at the world
> differently, but that's why DB2 ended up shipping its own copies of the ICU
> library. Once a user creates an object using ICU vX, we made sure that
> version of the library was always available to avoid these problems.
>

This seems like a terrible idea in the open source world. Surely collation
versioning means new ICU libraries can still provide the old collation
rules so even if you update the library you can request the old version? We
shouldn't need that actual old code with all its security holes and bugs
just to get the old collation version.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2018-09-17 19:46:01 Re: [HACKERS] proposal: schema variables
Previous Message Andrew Dunstan 2018-09-17 18:30:40 Re: pgsql: Allow concurrent-safe open() and fopen() in frontend code for Wi