Re: encode/decode support for base64url - Mailing list pgsql-hackers

From Chao Li
Subject Re: encode/decode support for base64url
Date
Msg-id 9D9864DE-86B9-4702-97CB-5D41A79BF77B@gmail.com
Whole thread Raw
In response to Re: encode/decode support for base64url  (Florents Tselai <florents.tselai@gmail.com>)
Responses Re: encode/decode support for base64url
List pgsql-hackers


On Sep 19, 2025, at 14:45, Florents Tselai <florents.tselai@gmail.com> 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/




pgsql-hackers by date:

Previous
From: Chao Li
Date:
Subject: Fix jsonb_from_cstring parameter type for length
Next
From: Frédéric Yhuel
Date:
Subject: Re: [BUG] temporary file usage report with extended protocol and unnamed portals