Re: Collation version tracking for macOS
Jeff Davis <pgsql@j-davis.com>
From: Jeff Davis <pgsql@j-davis.com>
To: Thomas Munro <thomas.munro@gmail.com>, Joe Conway <mail@joeconway.com>
Cc: Peter Eisentraut <peter.eisentraut@enterprisedb.com>, Jeremy Schneider <schneider@ardentperf.com>, Peter Geoghegan <pg@bowt.ie>, "Nasby, Jim" <nasbyj@amazon.com>, Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2023-01-20T20:54:28Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix copy&paste typo in comment
- 402388946fb3 17.0 cited
Attachments
- icu-multilib.html (application/xhtml+xml)
- v8-0004-icu_multilib-contrib-extension-for-managing-ICU-l.patch (text/x-patch) patch v8-0004
- v8-0003-Add-initdb-option-no-import-collations.patch (text/x-patch) patch v8-0003
- v8-0002-Add-test-module-for-icu-collation-provider-hook.patch (text/x-patch) patch v8-0002
- v8-0001-Support-multiple-ICU-collation-provider-libraries.patch (text/x-patch) patch v8-0001
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