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

Re: pg_dump --split patch

From: Joel Jacobson <joel(at)gluefinance(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, dmitry(at)koterov(dot)ru, 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:46:02
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> 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

That's actually what I first did a couple of months ago,

My major concern of parsing the schema file is I would never fully
trust the output from the script, even if the regex is extremely
paranoid and really strict, there is still a risk it contains a bug.

If you cannot trust the output from the schema parse script, it's not
safe to use it to do a partial restore of objects.
Let's say you want to restore only a few functions from your backup
schema. Without --split, you would need to restore them manually
somehow. With the --split option, you could simply restore them from
the indivudual files, at least functions where only the source code
has been modified and not the arguments.

2011/1/3 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> The basic objection that I have to this patch is that it proposes to
> institutionalize a pretty dumb implementation.  And, as you mentioned,

What's dumb about it? It's simple and it works.
Please give me an idea of what a smart implementation would be, and I
will see if I can rewrite the patch.

> 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.

Yes, that's why it should be a "bare minimum" solution to the problem,
which is a lot better than no solution at all.

What other variants than the discussion on the path name structure can
you think of?

> 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.

I'm quite sure such a postprocessing script has been written hundreds
of times over the past years by different postgres users, not even
submitting a question to the mailing list, since it's a quite
managable task for anyone with some regex and scripting experience.

Why not just provide a simple "bare minimum" solution to the "problem"
and let the remaining x % of the users who have a very specific need
write their own specialized script if they need to? It would save a
lot of time for all future users who need to write their own script to
solve the problem or google until they find my script or any other
script solving the same problem. Multiple almost identical solutions
to exactly the same problem is kind of time waste.

Best regards,

Joel Jacobson
Glue Finance

In response to


pgsql-hackers by date

Next:From: Dimitri FontaineDate: 2011-01-03 19:46:47
Subject: Re: Upgrading Extension, version numbers
Previous:From: David E. WheelerDate: 2011-01-03 19:43:43
Subject: Re: Upgrading Extension, version numbers (was: Extensions, patch v16)

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