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

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

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Jeff Davis <pgsql@j-davis.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-23T19:26:55Z
Lists: pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> Also, Noah has pointed out that C.UTF-8 introduces some
> forward-compatibility hazards of its own, at least with respect to
> ctype semantics. I don't have a clear view of what ought to be done
> about that, but if we just replace a dependency on an unstable set of
> libc definitions with a dependency on an equally unstable set of
> PostgreSQL definitions, we're not really winning.

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.

> Do we need to version the new ctype provider?

It would be a version for the underlying Unicode definitions,
not the provider as such, but perhaps yes.  I don't know to what
extent doing so would satisfy Noah's concern; but if it would do
so I'd be happy with that answer.

			regards, tom lane