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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [18] Policy on IMMUTABLE functions and Unicode updates
Дата
Msg-id 1083189.1721765253@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [18] Policy on IMMUTABLE functions and Unicode updates  (Jeff Davis <pgsql@j-davis.com>)
Ответы Re: [18] Policy on IMMUTABLE functions and Unicode updates
Список pgsql-hackers
Jeff Davis <pgsql@j-davis.com> writes:
> On Tue, 2024-07-23 at 15:26 -0400, Tom Lane wrote:
>> No, I think we *are* winning, because the updates are not "equally
>> unstable": with pg_c_utf8, we control when changes happen.  We can
>> align them with major releases and release-note the differences.
>> With libc-based collations, we have zero control and not much
>> notification.

> Also, changes to libc collations are much more impactful, at least two
> orders of magnitude. All indexes on text are at risk, even primary
> keys.

Well, it depends on which libc collation you have in mind.  I was
thinking of a libc-supplied C.UTF-8 collation, which I would expect
to behave the same as pg_c_utf8, modulo which Unicode version it's
based on.  But even when comparing to that, pg_c_utf8 can win on
stability for the reasons I stated.  If you don't have a C.UTF-8
collation available, and are forced to use en_US.UTF-8 or
$locale-of-choice, then the stability picture is far more dire,
as Jeff says.

Noah seems to be comparing the stability of pg_c_utf8 to the stability
of a pure C/POSIX collation, but I do not think that is the relevant
comparison to make.  Besides, if someone is using C/POSIX, this
feature doesn't stop them from continuing to do so.

            regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: [PATCH] GROUP BY ALL
Следующее
От: Jeff Davis
Дата:
Сообщение: Re: [18] Policy on IMMUTABLE functions and Unicode updates