Message-ID: <5ca35de8-48a6-6d9f-6f92-82d9da9ce227@joeconway.com>
Date: Tue, 29 Nov 2022 11:27:25 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.2
Content-Language: en-US
To: Robert Haas <robertmhaas@gmail.com>, Thomas Munro <thomas.munro@gmail.com>
Cc: Jeff Davis <pgsql@j-davis.com>,
 Peter Eisentraut <peter.eisentraut@enterprisedb.com>,
 Jeremy Schneider <schneider@ardentperf.com>, Peter Geoghegan <pg@bowt.ie>,
 "Finnerty, Jim" <jfinnert@amazon.com>, "Nasby, Jim" <nasbyj@amazon.com>,
 Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers <pgsql-hackers@postgresql.org>
References: <b37c2acd-24f4-07c9-da6e-6fec66137f69@enterprisedb.com>
 <D9EBBA4F-C92C-4B26-AB4D-6038BC52793D@ardentperf.com>
 <398aabd1-ad95-ba2d-d70a-dd5d90bf6e07@enterprisedb.com>
 <CA+hUKGL36vXMfcaDq+U1ZkoSsdfFnNx7GxhGM7aYzEbKs1W0=Q@mail.gmail.com>
 <CA+hUKGKq=iLH3bY+nK7v8b2zBCuKOk-fe0cP0it2RxNaWFVxYA@mail.gmail.com>
 <606bd2baa6d65b38fee6eb23bba40c5da210255b.camel@j-davis.com>
 <CA+hUKG+OSQtrRAk-bHwMJmuvqp-b-LGuxsF2PoDBVyQcT+VEAQ@mail.gmail.com>
 <9f8e9b5a3352478d4cf7d6c0a5dd7e82496be4b6.camel@j-davis.com>
 <CA+hUKGJxg6AbKC9RJ7r1ByVLtvVkThQV+RZO6BKVWYESPCp3Ug@mail.gmail.com>
 <CA+TgmoaTGBSLWYHA_TPz9Fc1TOa5aZ=2yXMrGbo9xU225Nv+YA@mail.gmail.com>
From: Joe Conway <mail@joeconway.com>
Subject: Re: Collation version tracking for macOS
In-Reply-To: 
 <CA+TgmoaTGBSLWYHA_TPz9Fc1TOa5aZ=2yXMrGbo9xU225Nv+YA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/5ca35de8-48a6-6d9f-6f92-82d9da9ce227%40joeconway.com>
Precedence: bulk

On 11/28/22 14:11, Robert Haas wrote:
> On Wed, Nov 23, 2022 at 12:09 AM Thomas Munro <thomas.munro@gmail.com> wrote:
>> OK.  Time for a new list of the various models we've discussed so far:
>>
>> 1.  search-by-collversion:  We introduce no new "library version"
>> concept to COLLATION and DATABASE object and little or no new syntax.
>>
>> 2.  lib-version-in-providers: We introduce a separate provider value
>> for each ICU version, for example ICU63, plus an unversioned ICU like
>> today.
>>
>> 3.  lib-version-in-attributes: We introduce daticuversion (alongside
>> datcollversion) and collicuversion (alongside collversion).  Similar
>> to the above, but it's a separate property and the provider is always
>> ICU.  New syntax for CREATE/ALTER COLLATION/DATABASE to set and change
>> ICU_VERSION.
>>
>> 4.  lib-version-in-locale:  "63:en" from earlier versions.  That was
>> mostly a strawman proposal to avoid getting bogged down in
>> syntax/catalogue/model change discussions while trying to prove that
>> dlopen would even work.  It doesn't sound like anyone really likes
>> this.
>>
>> 5.  lib-version-in-collversion:  We didn't explicitly discuss this
>> before, but you hinted at it: we could just use u_getVersion() in
>> [dat]collversion.
> 
> I'd like to vote against #3 at least in the form that's described
> here. If we had three more libraries providing collations, it's likely
> that they would need versioning, too. So if we add an explicit notion
> of provider version, then it ought not to be specific to libicu.

+many

> I think it's OK to decide that different library versions are
> different providers (your option #2), or that they are the same
> provider but give rise to different collations (your option #4), or
> that there can be multiple version of each collation which are
> distinguished by some additional provider version field (your #3 made
> more generic).

I think provider and collation version are distinct concepts. The 
provider ('c' versus 'i' for example) determines a unique code path in 
the backend due to different APIs, whereas collation version is related 
to a specific ordering given a set of characters.


> I don't really understand #1 or #5 well enough to have an educated
> opinion, but I do think that #1 seems a bit magical. It hopes that the
> combination of a collation name and a datcollversion will be
> sufficient to find exactly one matcing collation in a list of provided
> libraries. The advantage of that, as I understand it, is that if you
> do something to your system that causes the number of matches to go
> from one to zero, you can just throw another library on the pile and
> get the number back up to one. Woohoo! But there's a part of me that
> worries: what if the number goes up to two, and they're not all the
> same? Probably that's something that shouldn't happen, but if it does
> then I think there's kind of no way to fix it. With the other options,
> if there's some way to jigger the catalog state to match what you want
> to happen, you can always repair the situation somehow, because the
> library to be used for each collation is explicitly specified in some
> way, and you just have to get it to match what you want to have
> happen.

My vote is for something like #5. The collversion should indicate a 
specific immutable ordering behavior.


-- 
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com