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. 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. -- Robert Haas EDB: http://www.enterprisedb.com
