Re: Patch to document base64 encoding
От | Karl O. Pinc |
---|---|
Тема | Re: Patch to document base64 encoding |
Дата | |
Msg-id | 20190305072617.7d780265@slate.meme.com обсуждение исходный текст |
Ответ на | Re: Patch to document base64 encoding (Fabien COELHO <coelho@cri.ensmp.fr>) |
Ответы |
Re: Patch to document base64 encoding
|
Список | pgsql-hackers |
Hi Fabien, On Tue, 5 Mar 2019 07:09:01 +0100 (CET) Fabien COELHO <coelho@cri.ensmp.fr> wrote: > > Doc patch, against master. Documents encode() and decode() base64 > > format. > > It is already documented. Enhance documentation, though. Right. I was thinking that there are various implementations of the base64 data format and so it needed more than just to be named. > > Attached: doc_base64_v1.patch > > > > References RFC2045 section 6.8 to define base64. > > Did you consider referencing RFC 4648 instead? Not really. What drew me to document was the line breaks every 76 characters. So I pretty much went straight to the MIME RFC which says there should be breaks at 76 characters. I can see advantages and disadvantages either way. More or less extraneous information either semi or not base64 related in either RFC. Which RFC do you think should be referenced? Attached: doc_base64_v2.patch This new version adds a phrase clarifying that decode errors are raised when trailing padding is wrong. Seemed like I may as well be explicit. (I am not entirely pleased with the double dash but can't come up with anything better. And can't make an emdash entity work either.) Thanks for taking a look. Regards, Karl <kop@meme.com> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
Вложения
В списке pgsql-hackers по дате отправления: