Re: encode/decode support for base64url
Florents Tselai <florents.tselai@gmail.com>
From: Florents Tselai <florents.tselai@gmail.com>
To: Daniel Gustafsson <daniel@yesql.se>
Cc: "David E. Wheeler" <david@justatheory.com>, Aleksander Alekseev <aleksander@tigerdata.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>, Cary Huang <cary.huang@highgo.ca>, Przemysław Sztoch <przemyslaw@sztoch.pl>
Date: 2025-08-05T09:39:53Z
Lists: pgsql-hackers
> On 1 Aug 2025, at 1:13 PM, Florents Tselai <florents.tselai@gmail.com> wrote: > > > On Tue, Jul 29, 2025 at 3:25 PM Daniel Gustafsson <daniel@yesql.se <mailto:daniel@yesql.se>> wrote: >> > On 12 Jul 2025, at 21:40, David E. Wheeler <david@justatheory.com <mailto:david@justatheory.com>> wrote: >> >> > Thank you! This looks great. The attached revision makes a a couple of minor changes: >> >> I also had a look at this today and agree that it looks pretty close to being >> done, and a feature we IMHO would like to have. > > Thanks for having a look Daniel! > >> >> The attached version also adds a commit message, tweaks the documentation along >> with a few small changes to error message handling etc. > > In the doc snippet > > > The base64url alphabet use '-' instead of '+' and '_' instead of '/' and also omits the '=' padding character. > > Should be > > > The base64url alphabet uses '-' instead of '+' and '_' instead of '/', and also omits the '=' padding character. > > I'd also add a comma before "and also" > >> The base64 code this extends is the RFC 2045 variant while base64url is based >> on base64 from RFC 3548 (obsoleted by RFC 4648). AFAICT this is not a problem >> here but has anyone else verified this? > > I don't see how this can be a problem in practice. > The conversions are straightforward, > and the codepath used with url=true is a new one and doesn't change past behavior. Here’s a v6; necessary because func.sgml was split . No other changes compared to v5.