Re: Collation versioning

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: Collation versioning
Дата
Msg-id CAM-w4HNwnf9VGRaQgeAvuAupDBQQQEbJUXUxeU7wV_E9PjtaSw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Collation versioning  (Douglas Doole <dougdoole@gmail.com>)
Ответы Re: Collation versioning  (Douglas Doole <dougdoole@gmail.com>)
Список pgsql-hackers


On Mon 17 Sep 2018, 13:02 Douglas Doole, <dougdoole@gmail.com> wrote:
On Sun, Sep 16, 2018 at 1:14 PM Thomas Munro <thomas.munro@enterprisedb.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.

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: Stored procedures and out parameters
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: [HACKERS] proposal: schema variables