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

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: 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-09 17:03:06
Message-ID: CAKFQuwaJe6u-u4uSGtwSwgYkUfPSGLYkjCO+1Z_=WG937oraTQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-docs

On Sun, Feb 9, 2020 at 9:03 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> PG Doc comments form <noreply(at)postgresql(dot)org> writes:
>
> The base64 format is that of RFC 2045 Section 6.8. As per the RFC,
> encoded lines are broken at 76 characters
>

> > By the way, this is a very poor design decision.
>
> So far as I can tell, that RFC's requirement for line breaks has not
> been removed by any later RFC. So you're complaining to the wrong
> people.
>

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?

David J.

In response to

Responses

Browse pgsql-docs by date

  From Date Subject
Next Message Tom Lane 2020-02-09 19:24:05 Re: Documentation: 21.5. Default Roles
Previous Message Tom Lane 2020-02-09 16:08:55 Re: Lack of detailed documentation