Re: [18] Policy on IMMUTABLE functions and Unicode updates - Mailing list pgsql-hackers

From Jeremy Schneider
Subject Re: [18] Policy on IMMUTABLE functions and Unicode updates
Date
Msg-id CA+fnDAbJ_rnuFxMzKHeb6XSXmsf6vBv-5HCK1yG-p3_64fSxyQ@mail.gmail.com
Whole thread Raw
In response to Re: [18] Policy on IMMUTABLE functions and Unicode updates  (Robert Haas <robertmhaas@gmail.com>)
List 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?


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

pgsql-hackers by date:

Previous
From: Rafia Sabih
Date:
Subject: Re: Reducing the log spam
Next
From: Peter Eisentraut
Date:
Subject: Re: improve ssl error code, 2147483650