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 →
-
Add support for base64url encoding and decoding
- e1d917182c19 19 (unreleased) landed
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