| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | michael(at)qedcode(dot)com |
| Cc: | 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 15:49:50 |
| Message-ID: | 5732.1581263390@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-docs |
PG Doc comments form <noreply(at)postgresql(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2020-02-09 16:08:55 | Re: Lack of detailed documentation |
| Previous Message | David G. Johnston | 2020-02-08 20:32:12 | Re: Lack of detailed documentation |