Re: encode/decode support for base64url

Florents Tselai <florents.tselai@gmail.com>

From: Florents Tselai <florents.tselai@gmail.com>

To: Cary Huang <cary.huang@highgo.ca>

Cc: Daniel Gustafsson <daniel@yesql.se>, Aleksander Alekseev <aleksander@timescale.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>, Przemysław Sztoch <przemyslaw@sztoch.pl>

Date: 2025-03-11T08:08:06Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Add support for base64url encoding and decoding
- e1d917182c19 19 (unreleased) landed

Attachments

v2-0001-Add-base64url-in-encode-decode-functions.patch (application/octet-stream) patch v2-0001
v2-0002-Fix-declaration-after-statement.patch (application/octet-stream) patch v2-0002

On Tue, Mar 11, 2025 at 12:51 AM Cary Huang <cary.huang@highgo.ca> wrote:

> > Oh well - you're probably right.
> > I guess I was blinded by my convenience.
> > Adding a 'base64url' option there is more appropriate.
>
> I agree with it too. It is neater to add "base64url" as a new option for
> encode() and decode() SQL functions in encode.c.
>

Attaching a v2 with that.

>
> In addition, you may also want to add the C versions of base64rul encode
> and decode functions to "src/common/base64.c" as new API calls so that
> the frontend, backend applications and extensions can also have access
> to these base64url conversions.
>
>
We could expose this in base64.c - it'll need some more checking
A few more test cases, especially around padding, are necessary.
I'll come back to this.