> On 19 Sep 2025, at 6:50 AM, Chao Li <[email protected]> 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 <[email protected]> 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.
