Re: bytea_output output of base64

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
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-26 10:05:01
Message-ID: CA+Tgmoav1NdrCg-AsWG4i6bqho1vBeUnFCRWir3scX_ujHiViQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Feb 26, 2017 at 5:19 AM, Peter Eisentraut
<peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
>> Is there a reason we chose hex over base64?
>
> The reason we changed from the old format to hex was for performance.
> We didn't consider base64 at the time, but hex would probably still have
> been faster.

I might be remembering the discussion incorrectly, but I thought the
issue was that it was really hard to predict how large a buffer we
needed for the "escape" format, because the answer depends on the
number of backslashes in the string. With the "hex" format, we could
predict the size of the output just based on the size of the input
(which we know) rather than having it depend on the contents of the
input (which we don't). So I would think that any format that has the
property that we can know the exact output size based on the input
size would be equally good. And base64 would seem to have some
advantage because the output would be more substantially more compact.

That having been said, I do agree with Tom's point that we already
have one more bytea_output format than would be ideal. To justify
implementing base64 as a third choice, it would have to not only be
better than hex, but enough better to justify the migration pain. I'm
not sure whether it could clear that bar.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robins Tharakan 2017-02-26 10:13:46 Re: Allow pg_dumpall to work without pg_authid
Previous Message Erik Rijkers 2017-02-26 09:53:21 Re: Logical replication existing data copy