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

From Robert Haas
Subject Re: [18] Policy on IMMUTABLE functions and Unicode updates
Date
Msg-id CA+Tgmob6t-=Z-KtYA11AsiYSxdwrHNgi3ijn6cwtpdptA1-3PA@mail.gmail.com
Whole thread Raw
In response to Re: [18] Policy on IMMUTABLE functions and Unicode updates  (Peter Eisentraut <peter@eisentraut.org>)
Responses Re: [18] Policy on IMMUTABLE functions and Unicode updates
Re: [18] Policy on IMMUTABLE functions and Unicode updates
Re: [18] Policy on IMMUTABLE functions and Unicode updates
List pgsql-hackers
On Wed, Jul 24, 2024 at 12:42 AM Peter Eisentraut <peter@eisentraut.org> wrote:
> Fair enough.  My argument was, that topic is distinct from the topic of
> this thread.

OK, that's fair. But I think the solutions are the same: we complain
all the time about glibc and ICU shipping collations and not
versioning them. We shouldn't make the same kinds of mistakes. Even if
ctype is less likely to break things than collations, it still can,
and we should move in the direction of letting people keep the v17
behavior for the foreseeable future while at the same time having a
way that they can also get the new behavior if they want it (and the
new behavior should be the default).

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.

So I don't want to see us sit on our hands and assert that we don't
need to worry about ctype because it's minor in comparison with
collation. It *is* minor in comparison with collation. But one problem
can be small in comparison with another and still bad. If an aircraft
is on fire whilst experiencing a dual engine failure, it's still in a
lot of trouble even if the fire can be put out.

--
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Aleksander Alekseev
Date:
Subject: Re: [PATCH] Add additional extended protocol commands to psql: \parse and \bindx
Next
From: Ashutosh Sharma
Date:
Subject: Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions