Re: [HACKERS] bytea_output output of base64 - Mailing list pgsql-hackers

From Kenneth Marshall
Subject Re: [HACKERS] bytea_output output of base64
Date
Msg-id 20170224134414.GQ4234@aart.rice.edu
Whole thread Raw
In response to Re: [HACKERS] bytea_output output of base64  (David Fetter <david@fetter.org>)
Responses Re: [HACKERS] bytea_output output of base64  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
List pgsql-hackers
On Thu, Feb 23, 2017 at 03:52:46PM -0800, David Fetter wrote:
> On Thu, Feb 23, 2017 at 05:55:37PM -0500, Bruce Momjian wrote:
> > On Thu, Feb 23, 2017 at 04:08:58PM -0500, Tom Lane wrote:
> > > Bruce Momjian <bruce@momjian.us> writes:
> > > > Is there a reason we don't support base64 as a bytea_output output
> > > > option, except that no one has implemented it?
> > > 
> > > How about "we already have one too many bytea output formats"?
> > > I don't think forcing code to try to support still another one
> > > is a great thing ... especially not if it couldn't be reliably
> > > distinguished from the hex format.
> > 
> > Is there a reason we chose hex over base64?
> 
> Whether there was or not, there's not a compelling reason now to break
> people's software.  When people want compression, methods a LOT more
> effective than base64 are common.  Gzip, for example.
> 
> Best,
> David.

First, hex encoding is very simple to perform. Second, most applications
have routines to handle it trivially. And third, base64 encoding has some
padding constraints that can complicate is processing. Like David suggests,
if you want compact, run it through lz4/gzip/lzop...for a much better size
return.

Regards,
Ken



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: [HACKERS] FYI: git worktrees as replacement for "rsync theCVSROOT"
Next
From: Kohei KaiGai
Date:
Subject: Re: ParallelFinish-hook of FDW/CSP (Re: [HACKERS] Steps inside ExecEndGather)