Re: 9.4. String Functions and Operators page does not document that encode adds line breaks

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Michael L Perry <michael(at)qedcode(dot)com>, pgsql-docs(at)lists(dot)postgresql(dot)org
Subject: Re: 9.4. String Functions and Operators page does not document that encode adds line breaks
Date: 2020-02-27 18:32:56
Message-ID: 20200227183256.GA30538@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-docs

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.

--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-docs by date

  From Date Subject
Next Message Laurenz Albe 2020-02-28 09:24:23 Re: thoroughly broken examples on the Dynamic SQL page
Previous Message PG Doc comments form 2020-02-27 15:52:36 thoroughly broken examples on the Dynamic SQL page