Re: Collation version tracking for macOS
От | vignesh C |
---|---|
Тема | Re: Collation version tracking for macOS |
Дата | |
Msg-id | CALDaNm0dOJ1dBwVUH7i8Ak8Eaot+iK1iJeGy4vOi1tB=WK1E=A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Collation version tracking for macOS (Jeff Davis <pgsql@j-davis.com>) |
Ответы |
Re: Collation version tracking for macOS
(Jeff Davis <pgsql@j-davis.com>)
|
Список | pgsql-hackers |
On Sat, 21 Jan 2023 at 02:24, Jeff Davis <pgsql@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.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. 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
В списке pgsql-hackers по дате отправления:
Следующее
От: vignesh CДата:
Сообщение: Re: Dump-restore loosing 'attnotnull' bit for DEFERRABLE PRIMARY KEY column(s).