> On 12 Jul 2025, at 21:40, David E. Wheeler <da...@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. > * I kind of expected pg_base64url_encode to appear immediate after > pg_base64_encode. In other words, to see the two uses of > pg_base64_encode_internal adjacent to each other. I think that’s more typical > of the project standard. Same for the functions that call > pg_base64_decode_internal. +1, done in the attached. > * There are a few places where variable definition has been changed without > changing the meaning, for example: > ... > Even if this is desirable, it might make sense to defer pure formatting > changes to a separate patch. Agreed, the attached reverts stylistic changes. > * You define return variables in functions like pg_base64url_enc_len rather > than just returning the outcome of an expression. The latter is what I see in > pg_base64_enc_len, so I think would be more consistent. +1, done in the attached. The attached version also adds a commit message, tweaks the documentation along with a few small changes to error message handling etc. 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? -- Daniel Gustafsson
v5-0001-Add-support-for-base64url-encoding-and-decoding.patch
Description: Binary data
