Re: [HACKERS] bytea_output output of base64

2017-02-27 Thread Bruce Momjian
On Mon, Feb 27, 2017 at 09:28:10PM +0530, Robert Haas wrote: > I don't think Bruce was seriously proposing a change in this area > anyway. I think he was just asking a question. That is correct. I was asking if we made an obvious mistake, and most people are saying no. Also, base64 is less

Re: [HACKERS] bytea_output output of base64

2017-02-27 Thread Robert Haas
On Mon, Feb 27, 2017 at 7:08 PM, Peter Eisentraut wrote: > On 2/26/17 05:05, Robert Haas wrote: >> 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

Re: [HACKERS] bytea_output output of base64

2017-02-27 Thread Peter Eisentraut
On 2/26/17 05:05, Robert Haas wrote: > 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

Re: [HACKERS] bytea_output output of base64

2017-02-26 Thread Robert Haas
On Sun, Feb 26, 2017 at 5:19 AM, Peter Eisentraut 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

Re: [HACKERS] bytea_output output of base64

2017-02-25 Thread Bruce Momjian
On Sat, Feb 25, 2017 at 06:49:01PM -0500, Peter Eisentraut wrote: > On 2/23/17 17:55, Bruce Momjian wrote: > > On Thu, Feb 23, 2017 at 04:08:58PM -0500, Tom Lane wrote: > >> Bruce Momjian writes: > >>> Is there a reason we don't support base64 as a bytea_output output > >>>

Re: [HACKERS] bytea_output output of base64

2017-02-25 Thread Peter Eisentraut
On 2/23/17 17:55, Bruce Momjian wrote: > On Thu, Feb 23, 2017 at 04:08:58PM -0500, Tom Lane wrote: >> Bruce Momjian 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

Re: [HACKERS] bytea_output output of base64

2017-02-24 Thread Jim Nasby
On 2/24/17 7:44 AM, Kenneth Marshall wrote: Like David suggests, if you want compact, run it through lz4/gzip/lzop...for a much better size return. Speaking of which; any bytea where you care about this is likely to live in an already compressed state in toast. ISTM it would be valuable if we

Re: [HACKERS] bytea_output output of base64

2017-02-24 Thread Kenneth Marshall
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 writes: > > > > Is there a reason we don't support base64 as a

Re: [HACKERS] bytea_output output of base64

2017-02-24 Thread Fabien COELHO
It undoubtedly would make pg_dump smaller, though I'm not sure how much that's worth since if you care at all about that you'll gzip it. But, the other thing it might do is speed up COPY, especially on input. Some performance tests of that might be interesting. For what it is worth:

Re: [HACKERS] bytea_output output of base64

2017-02-23 Thread Jim Nasby
On 2/23/17 8:22 PM, Bruce Momjian wrote: I was just curious because it seems more compact than hex and many exchange formats use it, like SSL certificates and keys. I know you can encode() but I thought it might help make pg_dump output smaller. It undoubtedly would make pg_dump smaller,

Re: [HACKERS] bytea_output output of base64

2017-02-23 Thread Bruce Momjian
On Thu, Feb 23, 2017 at 07:09:57PM -0500, Andrew Dunstan wrote: > > > On 02/23/2017 06:52 PM, 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 writes: >

Re: [HACKERS] bytea_output output of base64

2017-02-23 Thread Andrew Dunstan
On 02/23/2017 06:52 PM, 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 writes: Is there a reason we don't support base64 as a bytea_output output

Re: [HACKERS] bytea_output output of base64

2017-02-23 Thread Tom Lane
David Fetter writes: > On Thu, Feb 23, 2017 at 05:55:37PM -0500, Bruce Momjian wrote: >> 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 >

Re: [HACKERS] bytea_output output of base64

2017-02-23 Thread David Fetter
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 writes: > > > Is there a reason we don't support base64 as a bytea_output output > > > option, except that no one has implemented it? > >

Re: [HACKERS] bytea_output output of base64

2017-02-23 Thread Bruce Momjian
On Thu, Feb 23, 2017 at 04:08:58PM -0500, Tom Lane wrote: > Bruce Momjian 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

Re: [HACKERS] bytea_output output of base64

2017-02-23 Thread Tom Lane
Bruce Momjian 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

[HACKERS] bytea_output output of base64

2017-02-23 Thread Bruce Momjian
Currently bytea_output supports values of 'hex' (the default) and 'escape' (octal). 'hex' uses two characters per byte, while escape uses three (ignoring the prefix overhead of \x or \[0-9].) It is my understanding that base64 uses 1.37 characters per byte: