| From: | Aleksander Alekseev <aleksander(at)tigerdata(dot)com> |
|---|---|
| To: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
| Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, 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-18 11:14:27 |
| Message-ID: | CAJ7c6TPu7NGrSj-V2-ns0GTNGx9cmoKQgzt-p2MpJepiGjQnYw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
> I've attached a patch for the 0002 patch part that fixes the above
> points (except for the last point) and has some minor fixes as well.
Applied, thanks.
> + /* Verify no extra bits remain (padding bits should be zero) */
> + if (bits_in_buffer > 0 && (bits_buffer & ((1ULL << bits_in_buffer)
> - 1)) != 0)
> + ereport(ERROR,
> + (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
> + errmsg("invalid base32hex end sequence"),
> + errhint("Input data has non-zero padding bits.")));
>
> 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)
>
> I think it's better to have consistent behavior across our encoding.
Agree. Fixed.
--
Best regards,
Aleksander Alekseev
| Attachment | Content-Type | Size |
|---|---|---|
| v6-0001-Allow-explicit-casting-between-bytea-and-UUID.patch | text/x-patch | 6.2 KB |
| v6-0002-Add-base32hex-encoding-support-to-encode-and-deco.patch | text/x-patch | 15.5 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dmitry Dolgov | 2026-03-18 11:18:52 | Re: Add ssl_(supported|shared)_groups to sslinfo |
| Previous Message | jian he | 2026-03-18 11:06:14 | Avoid some table rewrites for ALTER TABLE .. SET DATA TYPE array coerce |