On 3/18/25 16:30, Robert Haas wrote:
On Tue, Mar 18, 2025 at 3:50 PM Tom Lane <t...@sss.pgh.pa.us> wrote:
That approach works only if you sit on Unicode 15.1 *forever*.
The impracticality of that seems obvious to me. Sooner or later
you will need to update, and then you are going to suffer pain.
I completely agree.
The short answer is that "immutable" = "doesn't change till the heat
death of the universe" is a definition that is not useful when
dealing with this type of data. Other people determine the reality
that you have to deal with.
I think that's mostly true because of lack of versioning capabilities,
or crappy versioning practices. glibc, AIUI, just disclaims collation
stability: if you're fool enough to sort anything with one of their
collations, that's on you. To me, that seems like an obviously
user-hostile position, as if it were reasonable to suppose that an
algorithm whose whole purpose is to implement a sort order would not
be used for, uh, sorting. Or at least not any sort of sorting where
you don't immediately throw away the results (and then why did you
bother?). ICU doesn't seem to be entirely stable, either.
Yep
But none of that means stability isn't a valuable property. It just
means people have done a bad job implementing it. If we give people
the ability to execute operation X using ICU 15.1 or ICU 16.0,
they're still *eventually* going to have to migrate forward to ICU
16.0 or some later version, because we're probably not going to keep
ICU 15.1 until the heat death of the universe. But we allow people
to not have that update forced upon them at the same time they're
trying to change other things, and that's pretty darn useful. That's
why extensions have separate versioning from the server, for
instance.
+1 Robert articulates my thinking exactly, and much better than I did :-)
--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
