MIME-Version: 1.0
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>
In-Reply-To: 
 <CA+hUKGKWX6q_UXsDhVbhYns2+VsrPLW5o6ohqO6C=cZ6r23G7w@mail.gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
Date: Mon, 5 Dec 2022 10:45:26 -0500
Message-ID: 
 <CA+TgmoZ_qNa-GXAPcdRexF=JtCmVvo53wnEVzEBgoVaz3hspbQ@mail.gmail.com>
Subject: Re: Collation version tracking for macOS
To: 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>,
 "Nasby, Jim" <nasbyj@amazon.com>,
	Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers <pgsql-hackers@postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
 <https://www.postgresql.org/message-id/CA%2BTgmoZ_qNa-GXAPcdRexF%3DJtCmVvo53wnEVzEBgoVaz3hspbQ%40mail.gmail.com>
Precedence: bulk

On Sun, Dec 4, 2022 at 10:12 PM Thomas Munro <thomas.munro@gmail.com> wrote:
> My tentative votes are:
>
> 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.  This would include adding DDL
> commands so you can do ALTER DATABASE/COLLATION ... PROVIDER = ICU63
> to make warnings go way.

+1. I wouldn't lose any sleep if we picked a different non-magical
option, but I think this is probably my favorite of the
explicit-library-version options (though it is close) and I like it
better than search-by-collversion.

(It's possible that I'm wrong to like it better, but I do.)

> 2.  I think we should ignore minor versions for now (other than
> reporting them in the relevant introspection functions), but not make
> any choices that would prevent us from changing our mind about that in
> a later release.  For example, having two levels of specificity ICU
> and ICU68  in the libver-in-provider-name design wouldn't preclude us
> from adding support for ICU68_2 later

+1.

-- 
Robert Haas
EDB: http://www.enterprisedb.com