Horton

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

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jeff Davis <pgsql@j-davis.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Jeremy Schneider <schneider@ardentperf.com>, Laurenz Albe <laurenz.albe@cybertec.at>, Daniel Verite <daniel@manitou-mail.org>, Noah Misch <noah@leadboat.com>, Peter Eisentraut <peter@eisentraut.org>, pgsql-hackers@postgresql.org
Date: 2024-07-23T20:07:33Z
Lists: 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