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

> On 26 Mar 2026, at 04:40, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> 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.

To be precise, this discovery cast shadows on argument "[base32hex is ]lexicographically sortable format that preserves temporal ordering for UUIDv7". And, actually, any UUID. But I do not think it invalidates the argument completely.

It's taken from RFC[0], actually, that states:
One property with this alphabet, which the base64 and base32
alphabets lack, is that encoded data maintains its sort order when
the encoded data is compared bit-wise.

RFC does not give any other benefits.
Personally, I like that it's compact, visually better than base64, and RFC-compliant.
And IMO argument "base32hex is lexicographically sortable format that preserves ordering for UUID in C locale" is still very strong.
Though, there's a little footy shooty in last 3 words.

Best regards, Andrey Borodin.

[0] https://datatracker.ietf.org/doc/html/rfc4648#page-10