> On Sep 19, 2025, at 14:45, Florents Tselai <[email protected]> wrote:
>>
>> 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)
>
The current implementation isn’t actually wrong, but at least not optimized as
your version. Because we don’t need to check “if (p >= lend)” after p is
bumped, and only when “if (pos <0)”, p is bumped.
>
>>
>> 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.
I got to know this because once I reviewed a Tom Lane’s patch, it had the
similarly situation, but Tom wrote code like:
```
If (something)
Ereport(“function xxx”)
Else
Ereport(“procedure xxx”)
```
I raised a comment to suggest avoid duplicate code in the way like your code
do, and I got a response with “no” and the link.
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
