Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1jDweY-0005vd-QQ for pgsql-docs@arkaria.postgresql.org; Mon, 16 Mar 2020 20:48:02 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1jDweW-0008I1-9M for pgsql-docs@arkaria.postgresql.org; Mon, 16 Mar 2020 20:48:00 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1jDweW-0008Ht-1H for pgsql-docs@lists.postgresql.org; Mon, 16 Mar 2020 20:48:00 +0000 Received: from momjian.us ([72.94.173.45]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jDweT-00077r-1r for pgsql-docs@lists.postgresql.org; Mon, 16 Mar 2020 20:47:59 +0000 Received: from bruce by momjian.us with local (Exim 4.92) (envelope-from ) id 1jDweP-0007pr-2R; Mon, 16 Mar 2020 16:47:53 -0400 Date: Mon, 16 Mar 2020 16:47:53 -0400 From: Bruce Momjian To: Alvaro Herrera Cc: "David G. Johnston" , Tom Lane , Michael L Perry , pgsql-docs@lists.postgresql.org Subject: Re: 9.4. String Functions and Operators page does not document that encode adds line breaks Message-ID: <20200316204753.GB22592@momjian.us> References: <20200227183256.GA30538@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200227183256.GA30538@alvherre.pgsql> User-Agent: Mutt/1.10.1 (2018-07-13) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk 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 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? > > Patches welcome. > > I'm not sure that we *need* to preserve the historical behavior. Many > people would probably be okay with encode('base64') returning no > newlines (since they are useless most of the time anyway), and the > minority that does can use encode('base64-rfc2045'). > > Another idea might be to add an optional 'flags' option to encode(), > which are given to the encoder/decoder functions. I have had this force-wrap problem using Linux command-line tools. You can see it when using xxd here on page 54: https://momjian.us/main/writings/tls.pdf#page=54 xxd allows you to specify a maximum length, so I used -cols 999 to avoid the wrap. Other times I used a tool to remove the newlines from the output. I think you should just use the existing Postgres SQL string functions to remove the newlines. -- Bruce Momjian https://momjian.us EnterpriseDB https://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +