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

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [18] Policy on IMMUTABLE functions and Unicode updates
Дата
Msg-id CA+Tgmob6t-=Z-KtYA11AsiYSxdwrHNgi3ijn6cwtpdptA1-3PA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [18] Policy on IMMUTABLE functions and Unicode updates  (Peter Eisentraut <peter@eisentraut.org>)
Ответы 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
Список 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 по дате отправления:

Предыдущее
От: Aleksander Alekseev
Дата:
Сообщение: Re: [PATCH] Add additional extended protocol commands to psql: \parse and \bindx
Следующее
От: Ashutosh Sharma
Дата:
Сообщение: Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions