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

From Peter Geoghegan
Subject Re: Collation version tracking for macOS
Date
Msg-id CAH2-Wzmo74tMCLTHJm-WfbbjThoY9+fyzj+SHHY_W5edgmv+8g@mail.gmail.com
Whole thread Raw
In response to Re: Collation version tracking for macOS  ("Finnerty, Jim" <jfinnert@amazon.com>)
Responses Re: Collation version tracking for macOS
List 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 by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: pgcon unconference / impact of block size on performance
Next
From: Dagfinn Ilmari Mannsåker
Date:
Subject: Re: Logging query parmeters in auto_explain