| From: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
|---|---|
| To: | Aleksander Alekseev <aleksander(at)tigerdata(dot)com> |
| Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Chengxi Sun <chengxisun92(at)gmail(dot)com>, Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org> |
| Subject: | Re: Add uuid_to_base32hex() and base32hex_to_uuid() built-in functions |
| Date: | 2026-03-19 19:24:02 |
| Message-ID: | CAD21AoByeQny9oWUG4zoG1uv8X8d+hL6Rk0_vv_ahrkqY=Fa7A@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Mar 19, 2026 at 5:19 AM Aleksander Alekseev
<aleksander(at)tigerdata(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2026-03-19 19:24:36 | Re: Improve hash join's handling of tuples with null join keys |
| Previous Message | Sami Imseih | 2026-03-19 19:15:45 | Re: dshash_find_or_insert vs. OOM |