Re: Collation version tracking for macOS
От | Jeremy Schneider |
---|---|
Тема | Re: Collation version tracking for macOS |
Дата | |
Msg-id | D9EBBA4F-C92C-4B26-AB4D-6038BC52793D@ardentperf.com обсуждение исходный текст |
Ответ на | Re: Collation version tracking for macOS (Peter Eisentraut <peter.eisentraut@enterprisedb.com>) |
Ответы |
Re: Collation version tracking for macOS
Re: Collation version tracking for macOS |
Список | 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 по дате отправления: