From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
---|---|
To: | Jeff Davis <pgsql(at)j-davis(dot)com>, Joe Conway <mail(at)joeconway(dot)com>, Peter Eisentraut <peter(at)eisentraut(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Update Unicode data to Unicode 16.0.0 |
Date: | 2024-11-20 05:41:16 |
Message-ID: | 9e448ccc806f279a0855cc8d7dc2f598993014fe.camel@cybertec.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 2024-11-19 at 13:42 -0800, Jeff Davis wrote:
> On Tue, 2024-11-12 at 10:40 +0100, Laurenz Albe wrote:
> > I want to reiterate what I said in the above thread:
> > If that means that indexes on strings using the "builtin" collation
> > provider need to be reindexed after an upgrade, I am very much
> > against it.
>
> How would you feel if there was a better way to "lock down" the
> behavior using an extension?
Better.
> I have a patchset here:
>
> https://www.postgresql.org/message-id/78a1b434ff40510dc5aaabe986299a09f4da90cf.camel%40j-davis.com
>
> that changes the implementation of collation and ctype to use method
> tables rather than branching, and it also introduces some hooks that
> can be used to replace the method tables with whatever you want.
That looks like a nice idea, since it obviates the need to build
PostgreSQL yourself if you want to use a non-standard copy of - say -
the ICU library. You still have to build your own ICU library, though.
I had hoped that the builtin provider would remove the need to REINDEX,
but I have given up that hope. Peter's argument is sound from a
conceptual point of view, even though I doubt that the average user
will be able to appreciate it.
Yours,
Laurenz Albe
From | Date | Subject | |
---|---|---|---|
Next Message | Andrei Lepikhov | 2024-11-20 06:19:58 | Re: POC, WIP: OR-clause support for indexes |
Previous Message | Michael Paquier | 2024-11-20 05:22:39 | Re: fix deprecation mention for age() and mxid_age() |