Re: encode/decode support for base64url

Przemysław Sztoch <przemyslaw@sztoch.pl>

From: Przemysław Sztoch <przemyslaw@sztoch.pl>
To: Aleksander Alekseev <aleksander@timescale.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Cc: Daniel Gustafsson <daniel@yesql.se>
Date: 2025-03-10T23:01:26Z
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 →
  1. Add support for base64url encoding and decoding

On 07.03.2025 15:40, Aleksander Alekseev wrote:
> Hi,
>
>>> Sometimes support for base64url from RFC 4648 would be useful.
>>> Does anyone else need a patch like this?
>> While not a frequent ask, it has been mentioned in the past.  I think it would
>> make sense to add so please do submit a patch for it for consideration.
> IMO it would be nice to have.
>
> Would you like to submit such a patch or are you merely suggesting an
> idea for others to implement?

1. It is my current workaround:

SELECT convert_from(decode(rpad(translate(jwt_data, E'-_\n', '+/'), 
(ceil(length(translate(jwt_data, E'-_\n', '+/')) / 4::float) * 
4)::integer, '='::text), 'base64'), 'UTF-8')::jsonb AS jwt_json

But it's not very elegant. I won't propose my own patch, but if someone 
does it, I'll be very grateful for it. :-)

2. My colleagues also have a proposal to add hex_space, dec and dec_space.

hex_space and dec_space for obvious readability in some conditions.

dec and dec_space are also sometimes much more convenient for debugging 
and interpreting binary data by humans. 3. In addition to base64, 
sometimes base32 would be useful (both from rfc4648), which doesn't have 
such problems:

The resulting character set is all one case, which can often be 
beneficial when using a case-insensitive filesystem, DNS names, spoken 
language, or human memory. The result can be used as a file name because 
it cannot possibly contain the '/' symbol, which is the Unix path 
separator.

-- 
Przemysław Sztoch | Mobile +48 509 99 00 66