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

From Jeremy Schneider
Subject Re: Collation version tracking for macOS
Date
Msg-id D9EBBA4F-C92C-4B26-AB4D-6038BC52793D@ardentperf.com
Whole thread Raw
In response to Re: Collation version tracking for macOS  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Responses Re: Collation version tracking for macOS
Re: Collation version tracking for macOS
List pgsql-hackers
> On Jun 14, 2022, at 14:10, Peter Eisentraut <peter.eisentraut@enterprisedb.com> wrote:
> 
> Conversely, why are we looking at the ICU version instead of the collation version.  If we have recorded the
collationas being version 1234, we need to look through the available ICU versions (assuming we can load multiple ones
somehow)and pick the one that provides 1234.  It doesn't matter whether it's the same ICU version that the collation
wasoriginally created with, as long as the collation version stays the same. 

Does Unicode CDLR provide (or even track) versioning of collation or other i18n functionality for individual locale
settings?I’m thinking it might not even have that concept in the original source repo/data, but I might be remembering
wrong.

It would require not only watching for changes in the per-locale tailoring rules but also being cognizant of changes in
root/DUCETbehavior and understanding the impact of changes there. 

(Common mistake I’ve seen folks make when comparing OS glibc versions is only looking at locale data, not realizing
therehave been changes to root behavior that didn’t involve any changes to local data files) 

-Jeremy


pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: better page-level checksums
Next
From: Robert Haas
Date:
Subject: Re: better page-level checksums