On Tue, Feb 13, 2024 at 1:55 AM Jeff Davis <pg...@j-davis.com> wrote: > Postgres can and does latch on to the version of ICU it was compiled > against. It's a normal shared library dependency. > > The problem is that databases -- and the file structures -- outlive a > particular version of Postgres. So if Postgres 16 is compiled against > ICU X and Postgres 17 is compiled against ICU Y, how do you upgrade > from 16 to 17? Postgres 17 will try to access the old file structures > using ICU Y, and they'll be corrupt. > > What we want is the file structures that depend on ICU X to continue to > find ICU X even after you upgrade to Postgres 17, yet allow new > structures to be created using ICU Y. In other words, "multi-lib", > meaning that the same Postgres binary is linking to multiple versions > of ICU and the different versions for different structures. That would > allow users to recreate one index at a time to use ICU Y, until nothing > depends on ICU X any longer.
Ah, I see. At least, I think I do. I think some of this material could be very usefully included into the first section of the doc you're trying to write. What you say here makes it a lot easier to grasp the motivation and use case for this code, at least for me. -- Robert Haas EDB: http://www.enterprisedb.com
