public inbox for [email protected]
help / color / mirror / Atom feedFrom: Jeff Davis <[email protected]>
To: Thomas Munro <[email protected]>
Cc: Peter Eisentraut <[email protected]>
Cc: Jeremy Schneider <[email protected]>
Cc: Peter Geoghegan <[email protected]>
Cc: Nasby, Jim <[email protected]>
Cc: Tom Lane <[email protected]>
Cc: pgsql-hackers <[email protected]>
Subject: Re: Collation version tracking for macOS
Date: Mon, 05 Dec 2022 09:41:49 -0800
Message-ID: <[email protected]> (raw)
In-Reply-To: <CA+hUKGKWX6q_UXsDhVbhYns2+VsrPLW5o6ohqO6C=cZ6r23G7w@mail.gmail.com>
References: <[email protected]>
<[email protected]>
<[email protected]>
<CA+hUKGL36vXMfcaDq+U1ZkoSsdfFnNx7GxhGM7aYzEbKs1W0=Q@mail.gmail.com>
<CA+hUKGKq=iLH3bY+nK7v8b2zBCuKOk-fe0cP0it2RxNaWFVxYA@mail.gmail.com>
<[email protected]>
<CA+hUKG+OSQtrRAk-bHwMJmuvqp-b-LGuxsF2PoDBVyQcT+VEAQ@mail.gmail.com>
<[email protected]>
<CA+hUKGJxg6AbKC9RJ7r1ByVLtvVkThQV+RZO6BKVWYESPCp3Ug@mail.gmail.com>
<[email protected]>
<CA+hUKGJhPeW3iRqO3XQB=+BTMx7O6zTCFKTfeSV9TXBtdyMqbQ@mail.gmail.com>
<CA+hUKGLr=9d+-k8PVv8e__TOxuq=n0SKNDpqCzbGrK5EbDyxAg@mail.gmail.com>
<[email protected]>
<CA+hUKGKWX6q_UXsDhVbhYns2+VsrPLW5o6ohqO6C=cZ6r23G7w@mail.gmail.com>
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.
It avoids a lot of the annoyances we're discussing, and puts the power
in the hands of the admin. If they want to allow minor version updates,
they specify the library with .so.63, and let the symlinking handle it.
Of course, we can still do some sanity checks (WARNINGs or ERRORs) when
we think something is going wrong; like the version of ICU is too new,
or the reported version (ucol_getVersion()) doesn't match what's in
collversion. But we basically get out of the business of understanding
ICU versioning and leave that up to the administrator.
It's easier to document, and would require fewer GUCs (if any). And it
avoids mixing version information from another project into our data
model.
--
Jeff Davis
PostgreSQL Contributor Team - AWS
view thread (137+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Collation version tracking for macOS
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox