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

From Florents Tselai
Subject Re: encode/decode support for base64url
Date
Msg-id CA+v5N42bnuajC7c7d3xEVPFFacEsbmUL+sjPpQC8MLk6fyMgfg@mail.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
Attaching v6 again because it wasn't picked up the last time. 
Trying from Gmail's web page this time. 



On Tue, Aug 5, 2025 at 12:40 PM Florents Tselai <florents.tselai@gmail.com> wrote:


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> wrote:
> On 12 Jul 2025, at 21:40, David E. Wheeler <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.

 
Attachment

pgsql-hackers by date:

Previous
From: Shlok Kyal
Date:
Subject: Re: Skipping schema changes in publication
Next
From: Tomas Vondra
Date:
Subject: Re: Bug in brin_minmax_multi_distance_numeric()