From: | Jeremy Schneider <schneider(at)ardentperf(dot)com> |
---|---|
To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Nathan Bossart <nathandbossart(at)gmail(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: | 2025-03-16 01:23:37 |
Message-ID: | 449DFDB7-CE07-41DD-ABCE-6DA263606196@ardentperf.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On Mar 15, 2025, at 10:22 AM, Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
>
> On Sat, 2025-03-15 at 12:15 -0400, Tom Lane wrote:
>> On the other hand, if we keep up with the Joneses by updating the
>> Unicode data, we can hopefully put those behavioral changes into
>> effect *before* they'd affect any real data.
>
> That's a good point.
Jeff - thanks for the reminder that this is just about character semantics and not ordering. Obviously C collation by definition (code point ordering) doesn’t change sort order… two weeks ago I was working on updating the torture test GitHub page with glibc collation changes up through Ubuntu 24.10 so my mind was definitely over there. No detected changes in en-US so that’s great news. 🙂
Is the simple answer that functions & clauses related to both time zones and character semantics should just all be considered STABLE instead of IMMUTABLE?
I think if that were the case then changes across a minor version would simply be allowed by definition right? No need for warnings.
This would impact the ability to create case-insensitive indexes.
-Jeremy
Sent from my TI-83
From | Date | Subject | |
---|---|---|---|
Next Message | Corey Huinker | 2025-03-16 01:37:51 | Re: Statistics Import and Export |
Previous Message | Gurjeet Singh | 2025-03-16 00:14:14 | Re: Disabling vacuum truncate for autovacuum |