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.camel@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.
--
Jeff Davis
PostgreSQL Contributor Team - AWS