Skip site navigation (1) Skip section navigation (2)

Re: pg_dump --split patch

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: dmitry(at)koterov(dot)ru, Joel Jacobson <joel(at)gluefinance(dot)com>, Aidan Van Dyk <aidan(at)highrise(dot)ca>, Gurjeet Singh <singh(dot)gurjeet(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, Andrew Dunstan <andrew(at)dunslane(dot)net>, David Wilson <david(dot)t(dot)wilson(at)gmail(dot)com>
Subject: Re: pg_dump --split patch
Date: 2011-01-03 19:18:23
Message-ID: 23064.1294082303@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Jan 3, 2011 at 1:34 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Yeah, that's exactly it. I can think of some possible uses for
>> splitting up pg_dump output, but frankly "to ease diff-ing" is not
>> one of them. For that problem, it's nothing but a crude kluge that
>> only sort-of helps. If we're to get anywhere on this, we need a
>> better-defined problem statement that everyone can agree is worth
>> solving and is well solved with this particular approach.

> I have to admit I'm a bit unsold on the approach as well.  It seems
> like you could write a short Perl script which would transform a text
> format dump into the proposed format pretty easily, and if you did
> that and published the script, then the next poor shmuck who had the
> same problem could either use the script as-is or hack it up to meet
> some slightly different set of requirements.  Or maybe you'd be better
> off basing such a script on the custom or tar format instead, in order
> to avoid the problem of misidentifying a line beginning with --- as a
> comment when it's really part of a data item.  Or maybe even writing a
> whole "schema diff" tool that would take two custom-format dumps as
> inputs.

> On the other hand, I can certainly think of times when even a pretty
> dumb implementation of this would have saved me some time.

The basic objection that I have to this patch is that it proposes to
institutionalize a pretty dumb implementation.  And, as you mentioned,
once it's in there it'll be more or less set in stone because we aren't
going to want to support umpteen variants.

I like the idea of a postprocessing script a lot better --- it seems
like it wouldn't get in the way of people making their own variants.
And as you say it'd likely be pretty trivial to do.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Andrew DunstanDate: 2011-01-03 19:23:33
Subject: Re: back branches vs. VS 2008
Previous:From: David E. WheelerDate: 2011-01-03 19:13:26
Subject: Re: Extension upgrade, patch v0: debug help needed

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group