Re: Collation version tracking for macOS

Поиск
Список
Период
Сортировка
От Jeremy Schneider
Тема Re: Collation version tracking for macOS
Дата
Msg-id 450ADADD-FEE6-4217-A2C8-85F65DF52CD0@ardentperf.com
обсуждение исходный текст
Ответ на Collation version tracking for macOS  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Список pgsql-hackers
Дерево обсуждения



On Jun 14, 2022, at 19:06, Thomas Munro <thomas.munro@gmail.com> wrote:

One difference would be the effect if ICU ever ships a minor library
version update that changes the reported collversion.

If I’m reading it correctly, ICU would not change collation in major versions, as an explicit matter of policy around DUCET stability and versioning.



With some system of symlinks to make it all work with defaults for
those who don't care, a libc could have
/usr/share/locale/en_US@CLDR34.UTF-8 etc so you could
setlocale(LC_COLLATE, "en_US@CLDR34"), or something.  I suppose they
don't want to promise to be able to interpret the old data in future
releases, and, as you say, sometimes the changes are in C code, due to
bugs or algorithm changes, not the data.

If I understand correctly, files in /usr/share/locale aren’t enough because those only have the tailoring rules, and core algorithm and data (before applying locale-specific tweaks) also change between versions. I’m pretty sure glibc works similar to UCA in this regard (albeit based on ISO 14651 and not CDLR), and the Unicode link above is a good illustration of default collation rules that underly the locale-specific tweaks.

-Jeremy

Sent from my TI-83

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

Предыдущее
От: Zheng Li
Дата:
Сообщение: Re: Support logical replication of DDLs
Следующее
От: Masahiko Sawada
Дата:
Сообщение: Re: [BUG] Logical replication failure "ERROR: could not map filenode "base/13237/442428" to relation OID" with catalog modifying txns