| From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Jeremy Schneider <schneider(at)ardentperf(dot)com>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Daniel Verite <daniel(at)manitou-mail(dot)org>, Noah Misch <noah(at)leadboat(dot)com>, Peter Eisentraut <peter(at)eisentraut(dot)org>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: [18] Policy on IMMUTABLE functions and Unicode updates |
| Date: | 2024-07-23 19:56:28 |
| Message-ID: | 9a36d736cf807d9744916865f122ab9c863b3c2d.camel@j-davis.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, 2024-07-23 at 15:26 -0400, Tom Lane wrote:
> No, I think we *are* winning, because the updates are not "equally
> unstable": with pg_c_utf8, we control when changes happen. We can
> align them with major releases and release-note the differences.
> With libc-based collations, we have zero control and not much
> notification.
Also, changes to libc collations are much more impactful, at least two
orders of magnitude. All indexes on text are at risk, even primary
keys.
PG_C_UTF8 has stable code point ordering (memcmp()) that is unaffected
by Unicode updates, so primary keys will never be affected. The risks
we are talking about are for expression indexes, e.g. on LOWER(). Even
if you do have such expression indexes, the types of changes Unicode
makes to casing and character properties are typically much more mild.
Regards,
Jeff Davis
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2024-07-23 20:02:15 | Re: [PATCH] GROUP BY ALL |
| Previous Message | Nathan Bossart | 2024-07-23 19:55:28 | Re: pg_upgrade and logical replication |