From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bernd Helmle <mailings(at)oopsware(dot)de> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> |
Subject: | Re: bytea vs. pg_dump |
Date: | 2009-08-03 19:54:13 |
Message-ID: | 8056.1249329253@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | Postg토토 사이트SQL |
Bernd Helmle <mailings(at)oopsware(dot)de> writes:
> --On Montag, August 03, 2009 15:11:08 -0400 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
> wrote:
>> I'm starting to look at this patch. I observe that it's setting the
>> default output format to HEX. If changing the default behavior was
>> agreed to, or even discussed, I do not remember where. Shouldn't the
>> default stay the same?
> I would prefer it to be the default at least for pg_dump,
Well, we could have pg_dump force the output format to hex regardless
of what the default is.
A disadvantage of doing that is there wouldn't be any convenient way
to get pg_dump to *not* set the output format (unless we add a switch,
which seems way overkill). Which would mean there would be no good way
to get pg_dump to produce backwards-compatible output. But considering
how many other backwards-incompatible changes we have put into pg_dump
without blinking, I'm not sure this argument outweighs the probability
of breaking a lot of applications.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2009-08-03 19:54:22 | Re: fix: plpgsql: return query and dropped columns problem |
Previous Message | David Fetter | 2009-08-03 19:52:55 | Re: Alpha releases: How to tag |