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 no
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 an
On Sun, Feb 9, 2020 at 9:03 AM Tom Lane wrote:
> PG Doc comments form 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 requireme
PG Doc comments form writes:
> It took me a long time to discover why a base 64 encoded SHA-512 hash was 89
> characters long instead of the expected 88. The documentation does not
> mention that the encode function inserts newlines after 76 characters.
> Please make a note of this behavior.
That
On Sat, Feb 8, 2020 at 12:10 PM PG Doc comments form
wrote:
> The following documentation comment has been logged on the website:
>
> Page: https://www.postgresql.org/docs/12/functions-string.html
> Description:
>
> It took me a long time to discover why a base 64 encoded SHA-512 hash was
> 89
>
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/12/functions-string.html
Description:
It took me a long time to discover why a base 64 encoded SHA-512 hash was 89
characters long instead of the expected 88. The documentation does not
menti
