| From: | Jeremy Schneider <schneider(at)ardentperf(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Daniel Verite <daniel(at)manitou-mail(dot)org>, Jeff Davis <pgsql(at)j-davis(dot)com>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Noah Misch <noah(at)leadboat(dot)com>, Peter Eisentraut <peter(at)eisentraut(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: [18] Policy on IMMUTABLE functions and Unicode updates |
| Date: | 2024-07-24 19:43:44 |
| Message-ID: | CA+fnDAa6tNgj_C3mqPgyURPBQprQwwho4Km4xVeQ+SSaqrg5Ow@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Jul 24, 2024 at 12:47 PM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
On Wed, Jul 24, 2024 at 1:45 PM Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
> There's a qualitative difference between a collation update which can
> break your PKs and FKs, and a ctype update which definitely will not.
I don't think that's true. All you need is a unique index on UPPER(somecol).
I doubt it’s common to have unique on upper()
But non-unique indexes for case insensitive searches will be more common.
Historically this is the most common way people did case insensitive on
oracle.
Changing ctype would mean these queries can return wrong results
The impact would be similar to the critical problem TripAdvisor hit in 2014
with their read replicas, in the Postgres email thread I linked above
-Jeremy
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2024-07-24 19:47:12 | Re: [18] Policy on IMMUTABLE functions and Unicode updates |
| Previous Message | Heikki Linnakangas | 2024-07-24 19:27:14 | Re: Regarding t_cid in Neon heap WAL records |