On 2023-Jun-09, Tom Lane wrote: > Gurjeet Singh <gurj...@singh.im> writes: > > On Thu, Jun 8, 2023 at 7:35 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > >> This bug is very ancient, dating to commit 79d78bb26 which > >> added encode.c. (The other instances were presumably copied > >> from there.) Still, it doesn't quite seem worth back-patching. > > > Is it worth investing time in trying to unify these 3 occurrences of > > base64 length (and possibly other relevant) code to one place? If yes, > > I can volunteer for it. > > I wondered about that too. It seems really silly that we made > a copy in src/common and did not replace the others with calls > to that.
I looked into this. It turns out that there is a difference in newline handling in the other routines compared to what was added for SCRAM, which doesn't have any (and complains if you supply them). Peter E did suggest to unify them at the time: https://www.postgresql.org/message-id/947b9aff-8fdb-dbf5-a99c-0ffd4523a73f%402ndquadrant.com We could add a boolean "whitespace" flag to both of src/common/base64.c's pg_b64_encode() and pg_b64_decode(); with that I think it could serve the three places that need it. -- Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
