> On 26 Mar 2026, at 04:40, Tom Lane <[email protected]> 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
