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

From Joe Conway
Subject Re: Collation version tracking for macOS
Date
Msg-id 776e9ddb-a0e6-3f29-9368-a194be30d1a6@joeconway.com
Whole thread Raw
In response to Re: Collation version tracking for macOS  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: Collation version tracking for macOS
List pgsql-hackers
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




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Error-safe user functions
Next
From: Robert Haas
Date:
Subject: Re: Error-safe user functions