On Thu, Feb 27, 2020 at 03:32:56PM -0300, Alvaro Herrera wrote:
> On 2020-Feb-09, David G. Johnston wrote:
>
> > Stating direct RFC4648 compliance would require us to drop the line breaks
> > that are only being added due to using MIME rules which ideally our general
> > encoding function would not do. Greenfield we probably would want base64
> > to be general RFC4648 and add something like base64-mime which performs the
> > line breaking for the user per RFC 2045, base64-pem which would use that
> > specific environments RFC rules. Now, maybe we can add "base64-4648" or
> > "base64-general" while leaving "base64" alone and using the MIME version of
> > the rules?
>
> Patches welcome.
>
> I'm not sure that we *need* to preserve the historical behavior. Many
> people would probably be okay with encode('base64') returning no
> newlines (since they are useless most of the time anyway), and the
> minority that does can use encode('base64-rfc2045').
>
> Another idea might be to add an optional 'flags' option to encode(),
> which are given to the encoder/decoder functions.
I have had this force-wrap problem using Linux command-line tools. You
can see it when using xxd here on page 54:
https://momjian.us/main/writings/tls.pdf#page=54
xxd allows you to specify a maximum length, so I used -cols 999 to avoid
the wrap. Other times I used a tool to remove the newlines from the
output. I think you should just use the existing Postgres SQL string
functions to remove the newlines.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
