From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, 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-21 20:50:13 |
Message-ID: | 64e2885b01d385dc7f7c208bfaff517f0df85d15.camel@j-davis.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, 2024-11-20 at 06:41 +0100, Laurenz Albe wrote:
> 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.
It would work with the builtin provider, too, which would not require
ICU at all.
The idea is that you could build an extension that copies the same
logic for building the Unicode tables that we have in Postgres now,
except that it uses whatever version of the Unicode data files you
want.
If we want it to be targeted more specifically at the builtin provider,
we can make it even simpler by allowing you to just replace the unicode
tables with an extension (rather than the method tables). I'm not 100%
sure what people actually want here, so I'm open to suggestion.
> 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.
I'd like to provide options for all kinds of users and packagers.
Regards,
Jeff Davis
From | Date | Subject | |
---|---|---|---|
Next Message | Alexandra Wang | 2024-11-21 20:52:49 | Re: SQL:2023 JSON simplified accessor support |
Previous Message | Robert Haas | 2024-11-21 20:43:58 | Re: Replace current implementations in crypt() and gen_salt() to OpenSSL |