Re: Add uuid_to_base32hex() and base32hex_to_uuid() built-in functions - Mailing list pgsql-hackers

From Masahiko Sawada
Subject Re: Add uuid_to_base32hex() and base32hex_to_uuid() built-in functions
Date
Msg-id CAD21AoByeQny9oWUG4zoG1uv8X8d+hL6Rk0_vv_ahrkqY=Fa7A@mail.gmail.com
Whole thread
In response to Re: Add uuid_to_base32hex() and base32hex_to_uuid() built-in functions  (Aleksander Alekseev <aleksander@tigerdata.com>)
List pgsql-hackers
On Thu, Mar 19, 2026 at 5:19 AM Aleksander Alekseev
<aleksander@tigerdata.com> wrote:
>
> Hi,
>
> > I might be missing some context here, so I wanted to ask: is this behavior intentional,
> > or would it make sense to enforce stricter validation for Base32hex input?
>
> That's intentional - see the discussion above:
>
> """
> [...]
> This code checks if the remaining bits of the input data are all zero.
> IIUC we don't have a similar check for base64 and base64url. For
> instance, the following input data is accepted:
>
> =# select decode('AB', 'base64');
>  decode
> --------
>  \x00
> (1 row)
> """

Right. I've also tested base32hex encoding/decoding with other
libraries such as python's one. IIUC our base32hex implementation
doesn't necessarily work exactly the same as other libraries to have a
better consistency with the existing encodings such as base64 but I
believe that it doesn't contradict the RFC.

Regards,

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com



pgsql-hackers by date:

Previous
From: Sami Imseih
Date:
Subject: Re: dshash_find_or_insert vs. OOM
Next
From: Tom Lane
Date:
Subject: Re: Improve hash join's handling of tuples with null join keys