On Mon, Jun 6, 2022 at 5:45 PM Thomas Munro <thomas.mu...@gmail.com> 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
