On 3/26/26 00:40, Tom Lane wrote:
> Masahiko Sawada <sawada.mshk@gmail.com> writes:
>> I'm going to push the patch unless there are comments on these changes.
>
> BF member hippopotamus has just demonstrated that this
> "base32hex" representation is not in fact sort-stable at all [1]:
>
> SELECT array_agg(id ORDER BY guid_encoded) FROM guid3;
> array_agg
> ------------------------------
> - {1,2,3,4,5,6,7,8,9,10,11,12}
> + {12,1,2,3,4,5,7,6,8,9,10,11}
> (1 row)
>
> I believe what's happening there is that in cs_CZ locale,
> "V" doesn't follow simple ASCII sort ordering. (I don't
> know the exact rules in Czech, but certainly we've seen
> that locale break a lot of other test queries.)
>
With cs_CZ all letters sort *before* numbers, while in en_US it's the
other way around. V is not special in any way.
> I wonder whether this discovery puts enough of a hole in the
> value-proposition for base32hex that we should just revert
> this patch altogether. "It works except in some locales"
> isn't a very appetizing prospect, so the whole idea is starting
> to feel more like a foot-gun than a widely-useful feature.
>
Seems like that.
regards
--
Tomas Vondra
