Content-Type: multipart/alternative;
 boundary=Apple-Mail-91ED8638-32EC-4479-B85D-0CAD0D2D7A3B
Content-Transfer-Encoding: 7bit
From: Jeremy Schneider <schneider@ardentperf.com>
Mime-Version: 1.0 (1.0)
Subject: Re: Collation version tracking for macOS
Message-Id: <450ADADD-FEE6-4217-A2C8-85F65DF52CD0@ardentperf.com>
Date: Tue, 14 Jun 2022 20:40:22 -0400
Cc: Peter Eisentraut <peter.eisentraut@enterprisedb.com>,
 Peter Geoghegan <pg@bowt.ie>, "Finnerty, Jim" <jfinnert@amazon.com>,
 "Nasby, Jim" <nasbyj@amazon.com>, Tom Lane <tgl@sss.pgh.pa.us>,
 pgsql-hackers <pgsql-hackers@postgresql.org>
To: Thomas Munro <thomas.munro@gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/450ADADD-FEE6-4217-A2C8-85F65DF52CD0%40ardentperf.com>
Precedence: bulk


--Apple-Mail-91ED8638-32EC-4479-B85D-0CAD0D2D7A3B
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

=EF=BB=BF
=EF=BB=BF

> 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=E2=80=99m reading it correctly, ICU would not change collation in major=
 versions, as an explicit matter of policy around DUCET stability and versio=
ning.

https://unicode.org/reports/tr10/#Stable_DUCET


> 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=E2=80=99t enough b=
ecause those only have the tailoring rules, and core algorithm and data (bef=
ore applying locale-specific tweaks) also change between versions. I=E2=80=99=
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 d=
efault collation rules that underly the locale-specific tweaks.

-Jeremy

Sent from my TI-83=

--Apple-Mail-91ED8638-32EC-4479-B85D-0CAD0D2D7A3B
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div dir=3D"ltr">=EF=BB=BF<meta http-equiv=3D=
"content-type" content=3D"text/html; charset=3Dutf-8"><div dir=3D"ltr">=EF=BB=
=BF<meta http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf-8">=
<div dir=3D"ltr"><meta http-equiv=3D"content-type" content=3D"text/html; cha=
rset=3Dutf-8"><div dir=3D"ltr"><meta http-equiv=3D"content-type" content=3D"=
text/html; charset=3Dutf-8"><div dir=3D"ltr"><br></div><div dir=3D"ltr"><blo=
ckquote type=3D"cite">On Jun 14, 2022, at 19:06, Thomas Munro &lt;thomas.mun=
ro@gmail.com&gt; wrote:<br><br></blockquote></div><blockquote type=3D"cite">=
<div dir=3D"ltr"><span>One difference would be the effect if ICU ever ships a=
 minor library</span><br><span>version update that changes the reported coll=
version.</span><br></div></blockquote><div><br></div><div><div>If I=E2=80=99=
m reading it correctly, ICU would not change collation in major versions, as=
 an explicit matter of policy around DUCET stability and versioning.</div><d=
iv><br></div><div><a href=3D"https://unicode.org/reports/tr10/#Stable_DUCET"=
>https://unicode.org/reports/tr10/#Stable_DUCET</a></div><div><br></div><div=
><br></div></div><blockquote type=3D"cite"><div dir=3D"ltr"><span></span><sp=
an>With some system of symlinks to make it all work with defaults for</span>=
<br><span>those who don't care, a libc could have</span><br><span>/usr/share=
/locale/en_US@CLDR34.UTF-8 etc so you could</span><br><span>setlocale(LC_COL=
LATE, "en_US@CLDR34"), or something. &nbsp;I suppose they</span><br><span>do=
n't want to promise to be able to interpret the old data in future</span><br=
><span>releases, and, as you say, sometimes the changes are in C code, due t=
o</span><br><span>bugs or algorithm changes, not the data.</span><br></div><=
/blockquote><div><br></div><div>If I understand correctly, files in /usr/sha=
re/locale aren=E2=80=99t enough because those only have the tailoring rules,=
 and core algorithm and data (before applying locale-specific tweaks) also c=
hange between versions. I=E2=80=99m pretty sure glibc works similar to UCA i=
n 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 lo=
cale-specific tweaks.</div><div><br></div><div><div>-Jeremy</div><div><br><d=
iv dir=3D"ltr">Sent from my TI-83</div></div></div></div></div></div></div><=
/body></html>=

--Apple-Mail-91ED8638-32EC-4479-B85D-0CAD0D2D7A3B--