public inbox for [email protected]
help / color / mirror / Atom feedFrom: Peter Geoghegan <[email protected]>
To: Thomas Munro <[email protected]>
Cc: Jim Nasby <[email protected]>
Cc: Tom Lane <[email protected]>
Cc: Jeremy Schneider <[email protected]>
Cc: Peter Eisentraut <[email protected]>
Cc: pgsql-hackers <[email protected]>
Subject: Re: Collation version tracking for macOS
Date: Tue, 7 Jun 2022 13:16:21 -0700
Message-ID: <CAH2-Wzke2fShu2SQy53dywwJBgbj25uJ4P1NHXUvNqf5VHo_mQ@mail.gmail.com> (raw)
In-Reply-To: <CA+hUKGJ_CMXi6G1975Eo7S28Udri-3+FasF0+eNL5RVt4O=J8A@mail.gmail.com>
References: <[email protected]>
<CA+hUKGKjkL=APm5nd3vGOtMAD_07nyvrbAaGaDduVD-EKM5Drw@mail.gmail.com>
<[email protected]>
<[email protected]>
<[email protected]>
<CA+hUKGLwT9xBSodtmio-NnGXfkrfVs02O6kg1iwBJSt-XMhW4g@mail.gmail.com>
<[email protected]>
<[email protected]>
<CA+hUKGJ_CMXi6G1975Eo7S28Udri-3+FasF0+eNL5RVt4O=J8A@mail.gmail.com>
On Mon, Jun 6, 2022 at 5:45 PM Thomas Munro <[email protected]> wrote:
> Earlier I mentioned distinct "providers" but I take that back, that's
> too complicated. Reprising an old idea that comes up each time we
> talk about this, this time with some more straw-man detail: what about
> teaching our ICU support to understand "libicu18n.so.71:en" to mean
> that it should dlopen() that library and use its functions? Or some
> cleverer, shorter notation. Then it's the user's problem to make sure
> the right libraries are installed, and it'll fail if they're not. For
> example, on Debian bookworm right now you can install libicu63,
> libicu67, libicu71, though only the "current" -dev package, but which
> I'm sure we can cope with. You're at the mercy of the distro or
> add-on package repos to keep a lot of versions around, but that seems
> OK.
Right. Postgres could link to multiple versions of ICU at the same
time. Right now it doesn't, and right now the ICU C symbol names that
we use are actually versioned (this isn't immediately apparent because
the C preprocessor makes it appear that ICU symbol names are generic).
We could perhaps invent a new indirection that knows about
multiple ICU versions, each of which is an independent collation
provider, or maybe a related collation provider that gets used by
default on REINDEX. ICU is designed for this kind of thing. That
approach more or less puts packagers on the hook for managing
collation stability. But now long term collation stability is at least
feasible -- we at least have a coherent strategy. In the worst case
the community .deb and .rpm repos might continue to support an older
ICU version, or lobby for its continued support by the distro (while
actively discouraging its use in new databases). This isn't the same
thing as forking ICU. It's a compromise between that extreme, and
the current situation.
--
Peter Geoghegan
view thread (139+ 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]
Subject: Re: Collation version tracking for macOS
In-Reply-To: <CAH2-Wzke2fShu2SQy53dywwJBgbj25uJ4P1NHXUvNqf5VHo_mQ@mail.gmail.com>
* 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