Re: encode/decode support for base64url

From: Przemysław Sztoch <przemyslaw(at)sztoch(dot)pl>
To: Aleksander Alekseev <aleksander(at)timescale(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Cc: Daniel Gustafsson <daniel(at)yesql(dot)se>
Subject: Re: encode/decode support for base64url
Date: 2025-03-10 23:01:26
Message-ID: 40498a96-add5-4583-8d37-6fc3623901d4@sztoch.pl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2025-03-10 23:29:27 Re: Parallel heap vacuum
Previous Message Cary Huang 2025-03-10 22:51:06 Re: encode/decode support for base64url