Re: Collation versioning

Поиск
Список
Период
Сортировка
От Douglas Doole
Тема Re: Collation versioning
Дата
Msg-id CADE5jYKy9YxWucVENdpPMRj3yy97oN8Nvxo9ZsrLdDyxWykasQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Collation versioning  (Greg Stark <stark@mit.edu>)
Ответы Re: Collation versioning  (Thomas Munro <thomas.munro@enterprisedb.com>)
Список pgsql-hackers
On Mon, Sep 17, 2018 at 12:32 PM Greg Stark <stark@mit.edu> wrote:
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.

We asked long and hard for this feature from the ICU team but they kept arguing it was too hard to do. There are apparently some tight couplings between the code and each version of CLDR. So the only way to support old collations is to ship the entire old library. (They even added make rules to allow the entire API to be version extended to accommodate this requirement.)

Even bug fixes are potentially problematic because the fix may alter how some code points collate. The ICU team won't (or at least wouldn't - been a few years since I dealt with them) guarantee any sort of backwards compatibility between code drops.

As an aside, they did look at making the CLDR data a separate data file that could be read by any version of the code (before finding there were too many dependencies). One thing that they discovered is that this approach didn't save much disk since the CLDR data is something like 90-95% of the library. So while it would have made the calling code a lot cleaner, it wasn't the huge footprint win we'd been hoping for.

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

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: [HACKERS] proposal: schema variables
Следующее
От: Thomas Munro
Дата:
Сообщение: Re: Collation versioning