Re: Collation version tracking for macOS
От | Peter Geoghegan |
---|---|
Тема | Re: Collation version tracking for macOS |
Дата | |
Msg-id | CAH2-Wzmo74tMCLTHJm-WfbbjThoY9+fyzj+SHHY_W5edgmv+8g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Collation version tracking for macOS ("Finnerty, Jim" <jfinnert@amazon.com>) |
Ответы |
Re: Collation version tracking for macOS
|
Список | pgsql-hackers |
On Thu, Jun 9, 2022 at 2:20 PM Finnerty, Jim <jfinnert@amazon.com> wrote: > Specifying the library name before the language-country code with a new separator (":") as you suggested below has somebenefits. Did you consider making the collation version just another collation attribute, such as colStrength, colCaseLevel,etc.? > For example, an alternate syntax might be: > > create collation icu63."en-US-x-icu" (provider = icu, locale = 'en-US@colVersion=63'); Why would a user want to specify an ICU version in DDL? Wouldn't that break in the event of a dump and reload of the database, for example? It also strikes me as being inconsistent with the general philosophy for ICU and the broader BCP45 IETF standard, which is "interpret the locale string to the best of our ability, never throw an error". Your proposed syntax already "works" today! You just need to create a schema called icu63 -- then the command executes successfully (for certain values of successfully). I'm not arguing against the need for something like this. I'm just pointing out that there are good reasons to imagine that it would largely be an implementation detail, perhaps only used to unambiguously identify which specific ICU version and locale string relate to which on-disk relfilenode structure currently. -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: