Message-ID: <776e9ddb-a0e6-3f29-9368-a194be30d1a6@joeconway.com>
Date: Mon, 5 Dec 2022 12:45:46 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.4.2
Subject: Re: Collation version tracking for macOS
Content-Language: en-US
To: Jeff Davis <pgsql@j-davis.com>, Thomas Munro <thomas.munro@gmail.com>
Cc: Peter Eisentraut <peter.eisentraut@enterprisedb.com>,
 Jeremy Schneider <schneider@ardentperf.com>, Peter Geoghegan <pg@bowt.ie>,
 "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>
 <346f836208a39009c1998ed5a41c7f1a0be36911.camel@j-davis.com>
 <CA+hUKGJhPeW3iRqO3XQB=+BTMx7O6zTCFKTfeSV9TXBtdyMqbQ@mail.gmail.com>
 <CA+hUKGLr=9d+-k8PVv8e__TOxuq=n0SKNDpqCzbGrK5EbDyxAg@mail.gmail.com>
 <d8656ac98e1957401a21428949e98c840badf674.camel@j-davis.com>
 <CA+hUKGKWX6q_UXsDhVbhYns2+VsrPLW5o6ohqO6C=cZ6r23G7w@mail.gmail.com>
 <dae66ea33c91c597692522d2eabfee46ae799b54.camel@j-davis.com>
From: Joe Conway <mail@joeconway.com>
In-Reply-To: <dae66ea33c91c597692522d2eabfee46ae799b54.camel@j-davis.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/776e9ddb-a0e6-3f29-9368-a194be30d1a6%40joeconway.com>
Precedence: bulk

On 12/5/22 12:41, Jeff Davis wrote:
> On Mon, 2022-12-05 at 16:12 +1300, Thomas Munro wrote:
>> 1.  I think we should seriously consider provider = ICU63.  I still
>> think search-by-collversion is a little too magical, even though it
>> clearly can be made to work.  Of the non-magical systems, I think
>> encoding the choice of library into the provider name would avoid the
>> need to add a second confusing "X_version" concept alongside our
>> existing "X_version" columns in catalogues and DDL syntax, while
>> still
>> making it super clear what is going on.
> 
> As I understand it, this is #2 in your previous list?
> 
> Can we put the naming of the provider into the hands of the user, e.g.:
> 
>    CREATE COLLATION PROVIDER icu63 TYPE icu
>      AS '/path/to/libicui18n.so.63', '/path/to/libicuuc.so.63';
> 
> In this model, icu would be a "provider kind" and icu63 would be the
> specific provider, which is named by the user.
> 
> That seems like the least magical approach, to me. We need an ICU
> library; the administrator gives us one that looks like ICU; and we're
> happy.

+1

I like this. The provider kind defines which path we take in our code, 
and the specific library unambiguously defines a specific collation 
behavior (I think, ignoring bugs?)

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