Re: bytea_output output of base64

From: Kenneth Marshall <ktm(at)rice(dot)edu>
To: David Fetter <david(at)fetter(dot)org>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: bytea_output output of base64
Date: 2017-02-24 13:44:14
Message-ID: 20170224134414.GQ4234@aart.rice.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)momjian(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kohei KaiGai 2017-02-24 13:59:58 Re: ParallelFinish-hook of FDW/CSP (Re: Steps inside ExecEndGather)
Previous Message Andrew Dunstan 2017-02-24 13:10:50 Re: FYI: git worktrees as replacement for "rsync the CVSROOT"