Re: [18] Policy on IMMUTABLE functions and Unicode updates

Jeremy Schneider <schneider@ardentperf.com>

From: Jeremy Schneider <schneider@ardentperf.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Daniel Verite <daniel@manitou-mail.org>, Jeff Davis <pgsql@j-davis.com>, Laurenz Albe <laurenz.albe@cybertec.at>, Noah Misch <noah@leadboat.com>, Peter Eisentraut <peter@eisentraut.org>, Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgresql.org
Date: 2024-07-24T13:29:31Z
Lists: pgsql-hackers
On Wed, Jul 24, 2024 at 6:20 AM Robert Haas <robertmhaas@gmail.com> wrote:

>
> I note in passing that the last time I saw a customer query with
> UPPER() in the join clause was... yesterday. The problems there had
> nothing to do with CTYPE, but there's no reason to suppose that it
> couldn't have had such a problem. I suspect the reason we don't hear
> about ctype problems now is that the collation problems are worse and
> happen in similar situations. But if all the collation problems went
> away, a subset of the same users would then be unhappy about ctype.


I have seen and created indexes on upper() functions a number of times too,
and I think this is not an uncommon pattern for case insensitive searching

Before glibc 2.28, there was at least one mailing list thread where an
unhappy person complained about collation problems; but for a number of
years before 2.28 I guess the collation changes were uncommon so it didn’t
get enough momentum to be considered a real problem until the problem
became widespread a few years ago?

https://www.postgresql.org/message-id/flat/BA6132ED-1F6B-4A0B-AC22-81278F5AB81E%40tripadvisor.com

I myself would prefer an approach here that sets a higher bar for
pg_upgrade not corrupting indexes, rather than saying it’s ok as long as
it’s rare

-Jeremy