From: Tom Lane <tgl@sss.pgh.pa.us>
To: michael@qedcode.com
cc: pgsql-docs@lists.postgresql.org
Subject: Re: 9.4. String Functions and Operators page does not document that
 encode adds line breaks
In-reply-to: <158117862544.1089.17282036641192025921@wrigleys.postgresql.org>
References: <158117862544.1089.17282036641192025921@wrigleys.postgresql.org>
Comments: In-reply-to PG Doc comments form <noreply@postgresql.org>
	message dated "Sat, 08 Feb 2020 16:17:05 +0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <5731.1581263390.1@sss.pgh.pa.us>
Content-Transfer-Encoding: 8bit
Date: Sun, 09 Feb 2020 10:49:50 -0500
Message-ID: <5732.1581263390@sss.pgh.pa.us>
Precedence: bulk

PG Doc comments form <noreply@postgresql.org> 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 was done a few weeks ago in HEAD:

https://www.postgresql.org/docs/devel/functions-binarystring.html

    The base64 format is that of RFC 2045 Section 6.8. As per the RFC,
    encoded lines are broken at 76 characters. However instead of the MIME
    CRLF end-of-line marker, only a newline is used for end-of-line. The
    decode function ignores carriage-return, newline, space, and tab
    characters. Otherwise, an error is raised when decode is supplied
    invalid base64 data — including when trailing padding is incorrect.

> 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.

			regards, tom lane