On 3/18/25 16:30, Robert Haas wrote:
> On Tue, Mar 18, 2025 at 3:50 PM Tom Lane <tgl@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
