On Tue, Jun 7, 2022 at 4:29 PM Thomas Munro <thomas.mu...@gmail.com> wrote:
> The difference is that Debian has libllvm-{11,12,13,14}-dev packages,
> but it does *not* have multiple -dev packages for libicu, just a
> single libicu-dev which can be used to compile and link against their
> chosen current library version. They do have multiple packages for
> the actual .so and allow them to be installed concurrently.
> Therefore, you could install N .sos and dlopen() them, but you *can't*
> write a program that compiles and links against N versions at the same
> time using their packages (despite IBM's work to make that possible,
> perhaps for use in their own databases).
I know that glibc has various facilities for versioning dynamic
libraries, which includes ways to control symbol visibility. It's
possible that IBM's work on ICU versioning didn't just build on a
generic facility like that because that approach wasn't sufficiently
portable, particularly with platforms like AIX. It's also possible
that we won't have any of these same requirements, and can feasibly
link against multiple ICU versions some other way, and ultimately
achieve the same result -- multiple versions of ICU that can be used
by Postgres at the same time, with long term stable collations across
major OS and Postgres versions.
I now understand that you agree with me on this basic and important
point. Must have been a miscommunication.
> > Packaging standards certainly matter, but they're not immutable laws
> > of the universe. It seems reasonable to suppose that the people that
> > define these standards would be willing to hear us out -- this is
> > hardly a trifling matter, or something that only affects a small
> > minority of *their* users.
>
> OK, yeah, I'm thinking within the confines of things we can do easily
> right now on existing systems as they are currently packaging software
> only by changing our code, not "tell Debian to change their packaging
> so we can compile and link against N versions".
There are lots of specifics here, and I'm certainly not an expert on
packaging. IMV our approach doesn't necessarily need to use the same
original canonical package, though. It just needs to provide a
reasonably smooth experience for users that actually need to keep
their old collations working on upgrade. Either way, the process needs
to be something where all parties understand the concerns of each
other.
Of course Debian doesn't support linking against multiple versions of
ICU right now; why would they? Is there any reason to think that even
one person ever asked about it? Our interest in doing that will
probably be totally unique from their point of view. Can we just ask
somebody about it that has a deep understanding of these things?
> Supposing Debian
> maintainers (and all the others) agreed, there'd still something else
> in favour of dlopen(): wouldn't it be nice if the users were not
> limited by the versions that the packager of PostgreSQL decided to
> link against? What if someone has a good reason to want to use ICU
> versions that are older than Debian currently ships, that are easily
> available in add-on repos?
I don't consider the ability to support many versions of ICU for the
sake of ICU features to be much of an advantage. I mostly just care
about the simple, common case where a user upgrades and doesn't want
to REINDEX immediately. You may well be right about dlopen(); I just
don't know right now.
> I think we're not understanding each other here: I was talking about
> the technical choice of whether we'd model the multiple library
> versions in our catalogues as different "collprovider" values, or
> somehow encode them into the "collcollate" string, or something else.
ISTM that there are two mostly-distinct questions here:
1. How do we link to multiple versions of ICU at the same time, in a
way that is going to work smoothly on mainstream platforms?
2. What semantics around collations do we want for Postgres once we
gain the ability to use multiple versions of ICU at the same time? For
example, do we want to generalize the definition of a collation, so
that it's associated with one particular ICU version and collation for
the purposes of on-disk compatibility, but isn't necessarily tied to
the same ICU version in other contexts, such as on a dump and restore?
--
Peter Geoghegan
