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

Sergey Prokhorenko <sergeyprokhorenko@yahoo.com.au>

From: Sergey Prokhorenko <sergeyprokhorenko@yahoo.com.au>

To: Andrey Borodin <x4mmm@yandex-team.ru>

Cc: pgsql-hackers <pgsql-hackers@postgresql.org>

Date: 2025-10-23T17:34:13Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Add base32hex support to encode() and decode() functions.
- 497c1170cb10 19 (unreleased) landed
Allow explicit casting between bytea and uuid.
- ba21f5bf8aff 19 (unreleased) landed
Add support for base64url encoding and decoding
- e1d917182c19 19 (unreleased) cited

>> The value of converting uuid to base32 is not obvious though, so I>> would recommend explaining it in more detail.

> Yes, and maybe some examples of other systems that adopted this format would be handy too.

DNSSEC (https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions)
many encoders and decoders
> Sergey, can you, please, extend reasoning why this particular format is prominent? RFC 4648 describes a bunch of formats.

> Best regards, Andrey Borodin.


Base32hex:1. Preserves sort order (unlike base64)2. Compact3. Standardized and therefore implemented consistently everywhere4. Implemented in many programming languages' standard libraries5. Does not require specifying character case during dictation6. Has simple and high-performance encoding and decoding algorithms (necessary for system integration using JSON)
The only compact text encoding eliminates the problem of incompatibility. The authors and contributors of RFC 9562 were categorically against having multiple encodings for UUIDs. They wanted to have only one compact, sort-order-preserving text encoding. For compatibility, they added the canonical UUID format. Due to time constraints, the compact encoding was not included in RFC 9562.
In databases, UUIDs should preferably be stored in binary format (the UUID type in PostgreSQL) according to RFC 9562.
Intermediate formats (bytea) reduce performance, which is the very reason we even abandoned the more compact base36 encoding.