From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
---|---|
To: | Jeff Davis <pgsql(at)j-davis(dot)com>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Joe Conway <mail(at)joeconway(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Update Unicode data to Unicode 16.0.0 |
Date: | 2025-01-22 18:08:10 |
Message-ID: | b27fd130-999c-446f-b8a0-ffad6e0ec49a@eisentraut.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 20.01.25 22:39, Jeff Davis wrote:
> On Fri, 2024-11-15 at 17:09 +0100, Peter Eisentraut wrote:
>> The practice of regularly updating the Unicode files is older than
>> the
>> builtin collation provider. It is similar to updating the time zone
>> files, the encoding conversion files, the snowball files, etc. We
>> need
>> to move all of these things forward to keep up with the aspects of
>> the
>> real world that this data reflects.
>
> Should we consider bundling multiple versions of the generated tables
> (header files) along with Postgres?
I wouldn't have a problem with that.
> That would enable a compile-time option to build with an older version
> of Unicode if you want, solving the packager concern that Noah raised.
> It would also make it easier for people to coordinate the Postgres
> version of Unicode and the ICU version of Unicode.
But I don't think it would be a compile-time decision. I think it would
be a run-time selection, similar to the theorized multiple-ICU-versions
feature. (Those two features might even go together, since a given ICU
version also sort of assumes a given Unicode version.)
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2025-01-22 18:15:59 | Re: Converting pqsignal to void return |
Previous Message | Peter Eisentraut | 2025-01-22 18:03:44 | Re: Update Unicode data to Unicode 16.0.0 |