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

Tomas Vondra <tomas(at)vondra(dot)me> writes:
> On 3/26/26 00:40, Tom Lane wrote:
>> I believe what's happening there is that in cs_CZ locale,
>> "V" doesn't follow simple ASCII sort ordering.

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

Ah, sorry, I should have researched a bit instead of relying on
fading memory. The quirk I was thinking of is that in cs_CZ,
"ch" sorts after "h":

u8=# select 'h' < 'ch'::text collate "en_US";
?column?
----------
f
(1 row)

u8=# select 'h' < 'ch'::text collate "cs_CZ";
?column?
----------
t
(1 row)

Regular hex encoding isn't bitten by that because it doesn't
use 'h' in the text form ... but this base32hex thingie does.

However, your point is also correct:

u8=# select '0' < 'C'::text ;
?column?
----------
t
(1 row)

u8=# select '0' < 'C'::text collate "cs_CZ";
?column?
----------
f
(1 row)

and that breaks "text ordering matches numeric ordering"
for both traditional hex and base32hex. So maybe this
is not as big a deal as I first thought. We need a fix
for the new test though. Probably adding COLLATE "C"
would be enough.

regards, tom lane