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

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.)

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.

regards, tom lane

[1] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hippopotamus&dt=2026-03-25%2022%3A38%3A14