Re: Add uuid_to_base32hex() and base32hex_to_uuid() built-in functions

On 3/26/26 00:40, Tom Lane wrote:
> Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)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