Re: encode/decode support for base64url

Florents Tselai <florents.tselai@gmail.com>

From: Florents Tselai <florents.tselai@gmail.com>
To: Daniel Gustafsson <daniel@yesql.se>
Cc: "David E. Wheeler" <david@justatheory.com>, Aleksander Alekseev <aleksander@tigerdata.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>, Cary Huang <cary.huang@highgo.ca>, Przemysław Sztoch <przemyslaw@sztoch.pl>
Date: 2025-08-01T10:13:23Z
Lists: pgsql-hackers
On Tue, Jul 29, 2025 at 3:25 PM Daniel Gustafsson <daniel@yesql.se> wrote:

> > On 12 Jul 2025, at 21:40, David E. Wheeler <david@justatheory.com>
> wrote:
>
> > Thank you! This looks great. The attached revision makes a a couple of
> minor changes:
>
> I also had a look at this today and agree that it looks pretty close to
> being
> done, and a feature we IMHO would like to have.


Thanks for having a look Daniel!


>
>
The attached version also adds a commit message, tweaks the documentation
> along
> with a few small changes to error message handling etc.
>

In the doc snippet

> The base64url alphabet use '-' instead of '+' and '_' instead of '/' and
also omits the '=' padding character.

Should be

> The base64url alphabet use*s* '-' instead of '+' and '_' instead of '/'*,
*and also omits the '=' padding character.

I'd also add a comma before "and also"


> The base64 code this extends is the RFC 2045 variant while base64url is
> based
> on base64 from RFC 3548 (obsoleted by RFC 4648).  AFAICT this is not a
> problem
> here but has anyone else verified this?
>

I don't see how this can be a problem in practice.
The conversions are straightforward,
and the codepath used with url=true is a new one and doesn't change past
behavior.