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  (Thomas Munro <thomas.munro@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: pgcon unconference / impact of block size on performance
Следующее
От: Dagfinn Ilmari Mannsåker
Дата:
Сообщение: Re: Logging query parmeters in auto_explain