Re: encode/decode support for base64url

> On 19 Sep 2025, at 6:50 AM, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> wrote:

Great to see you around Evan!

>
> I reviewed and tested this patch. Overall looks good to me. Actually, I think this patched fixed a bug of current implementation of base64 encoding by moving the logic of handling newline into “if (pos<0)”.

IIUC what you mean, I can’t confirm that.

Both existing and new implementation handle new lines the same

SELECT decode(E'QUFB\nQUFB', 'base64url');
decode
----------------
\x414141414141
(1 row)

>
> Just a few small comments:
>
>> On Sep 19, 2025, at 03:19, Daniel Gustafsson <daniel(at)yesql(dot)se> wrote:
>>
>> <v9-0001-Add-support-for-base64url-encoding-and-decoding.patch>
>
>
> 1.
> ```
> + * Helper for decoding base64 or base64url. When url is passed as true the
> + * input will be encoded using base64url. len bytes in src is encoded into
> + * dst.
> + */
> ```
>
> It’s not common to use two white-spaces after “.”, usually we need only one.

I agree with this

>
> 2.
> ```
> + /* handle remainder */
> if (pos != 2)
> ```
>
> The comment is understandable, but slightly vague: remainder of what?
>
> Maybe rephrase to “handle remaining bytes in buf”.

Agree too.

>
> 3.
> ```
> ereport(ERROR,
> (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
> - errmsg("unexpected \"=\" while decoding base64 sequence")));
> + errmsg("unexpected \"=\" while decoding %s sequence", url ? "base64url" : "base64")));
> ```
>
> This is a normal usage that injects sub-strings based on condition. However, PG doesn’t like that, see here: https://www.postgresql.org/docs/devel/nls-programmer.html#NLS-GUIDELINES

Well, that’s a very interesting catch.
I’ll let a comitter confirm & advise.