Re: Collation version tracking for macOS
Joe Conway <mail@joeconway.com>
From: Joe Conway <mail@joeconway.com>
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>
Date: 2022-12-05T17:45:46Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix copy&paste typo in comment
- 402388946fb3 17.0 cited
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