Re: encode/decode support for base64url

> On 12 Jul 2025, at 21:40, David E. Wheeler <david(at)justatheory(dot)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.

> * I kind of expected pg_base64url_encode to appear immediate after pg_base64_encode. In other words, to see the two uses of pg_base64_encode_internal adjacent to each other. I think that’s more typical of the project standard. Same for the functions that call pg_base64_decode_internal.

+1, done in the attached.

> * There are a few places where variable definition has been changed without changing the meaning, for example:
> ...
> Even if this is desirable, it might make sense to defer pure formatting changes to a separate patch.

Agreed, the attached reverts stylistic changes.

> * You define return variables in functions like pg_base64url_enc_len rather than just returning the outcome of an expression. The latter is what I see in pg_base64_enc_len, so I think would be more consistent.

+1, done in the attached.

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

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?

--
Daniel Gustafsson