Re: Collation version tracking for macOS - Mailing list pgsql-hackers

From Jeremy Schneider
Subject Re: Collation version tracking for macOS
Date
Msg-id 450ADADD-FEE6-4217-A2C8-85F65DF52CD0@ardentperf.com
Whole thread Raw
In response to Collation version tracking for macOS  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
List 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 by date:

Previous
From: Zheng Li
Date:
Subject: Re: Support logical replication of DDLs
Next
From: Masahiko Sawada
Date:
Subject: Re: [BUG] Logical replication failure "ERROR: could not map filenode "base/13237/442428" to relation OID" with catalog modifying txns