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

Jelte Fennema-Nio <postgres@jeltef.nl>

From: Jelte Fennema-Nio <postgres@jeltef.nl>

To: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>

Cc: Sergey Prokhorenko <sergeyprokhorenko@yahoo.com.au>, Andrey Borodin <x4mmm@yandex-team.ru>, Masahiko Sawada <sawada.mshk@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>

Date: 2025-10-28T12:24:49Z

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

On Tue, 28 Oct 2025 at 12:53, Dagfinn Ilmari Mannsåker
<ilmari@ilmari.org> wrote:
> If it's just one new form, do we need a separate decode function?  Could
> we not just make uuid_in() accept both forms (they're easily
> distinguishable by length), like bytea_in accepts both the old escape
> format and the new hex format?
>
> And if the new format becomes the standard and want to change the
> default output format, we would need a GUC like bytea_output anyway, to
> let users control when to make the change.

Agreed to both of those. This seems too far out to spend much time
discussing now.