On Sat, 21 Jan 2023 at 02:24, Jeff Davis <pg...@j-davis.com> wrote: > > On Thu, 2023-01-19 at 00:11 -0800, Jeff Davis wrote: > > Attached are a new set of patches, including a major enhancement: the > > icu_multilib contrib module. > > Attached rebased v8. > > [ It looks like my email client truncated the last email somehow, in > case someone was wondering why it just stopped. ] > > The big change is the introduction of the icu_multilib contrib module > which provides a lot of the functionality requested in this thread: > > * icu version stability, which allows you to "lock down" ICU to a > specific major and minor version (or major version only) > * multi-lib ICU, which (if a GUC is set) will enable the "search by > collversion" behavior. Some doubts were raised about the wisdom of this > approach, but it's the only multi-lib solution we have without doing > some significant catalog work. > > I rendered the HTML docs for icu_multilib and attached to this email to > make it easier to view. > > icu_multilib assumes that the various ICU library versions are already > available in a single location, most likely installed with a package > manager. That location can be the same as the built-in ICU, or a > different location. Ideally, packagers would start to offer a few > "stable" versions of ICU that would be available for a long time, but > it will take a while for that to happen. So for now, it's up to the > user to figure out how to get the right versions of ICU on their system > and keep them there. > > Automated tests of icu_multilib are a problem unless the one running > the tests is willing to compile the right versions of ICU (like I did). > But I at least have automated tests for the hooks by using the test > module test_collator_lib_hooks. > > The v7 patches in this thread are dependent on the pure refactoring > patches in this CF entry: > > https://commitfest.postgresql.org/41/3935/ > > https://postgr.es/m/052a5ed874d110be2f3ae28752e363306b10966d.ca...@j-davis.com > > The requested functionality _not_ offered by icu_multilib is tying a > specific collation to a specific ICU version. A few variants were > proposed, the latest is to tie a collation to the library file itself > through the provider. That needs to be done with proper catalog support > in core. But I believe the work I've done here has made a lot of > progress in that direction, and also shows the versatility of the new > hook to solve at least some problems.
This thread has been idle for a year now, It has stalled after a lot of discussion. @Jeff Davis: Do you want to try to restart the discussion by posting an updated version and see what happens? Regards, Vignesh
