Horton

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

Aleksander Alekseev <aleksander@tigerdata.com>

View thread
From: Aleksander Alekseev <aleksander@tigerdata.com>
To: pgsql-hackers <pgsql-hackers@postgresql.org>
Cc: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>, Jelte Fennema-Nio <postgres@jeltef.nl>, Sergey Prokhorenko <sergeyprokhorenko@yahoo.com.au>, Andrey Borodin <x4mmm@yandex-team.ru>, Masahiko Sawada <sawada.mshk@gmail.com>
Date: 2025-10-29T11:31:29Z
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 →

  1. Add base32hex support to encode() and decode() functions.

  2. Allow explicit casting between bytea and uuid.

  3. Add support for base64url encoding and decoding

Hi,

Thanks for the patch.

> That does seem like a better fit. It's used mainly in recv functions,
> which this basically is (but user-callable).
>
> Updated patch attaced.

Perhaps bytea_uuid() should check the UUID format. Consider the
following example:

SELECT uuid_extract_version('\x019a2f859cedffffb99d9c55044a2563'::bytea::uuid);
 uuid_extract_version
----------------------
                   15

There is no UUID version 15 according to RFC 9562, and the
documentation for uuid_extract_version() says:

"""
Extracts the version from a UUID of the variant described by RFC 9562.
For other variants, this function returns null. For example, for a
UUID generated by gen_random_uuid, this function will return 4.
"""

If I read this correctly, either bytea_uuid() should reject this, or
uuid_extract_version() should be modified to return NULL, or the
documentation for uuid_extract_version() should be altered.

-- 
Best regards,
Aleksander Alekseev