Re: Dump all except some tables? - Mailing list pgsql-general

From Jim C. Nasby
Subject Re: Dump all except some tables?
Date
Msg-id 20051008223316.GA36108@pervasive.com
Whole thread Raw
In response to Re: Dump all except some tables?  (David Fetter <david@fetter.org>)
List pgsql-general
On Sat, Oct 08, 2005 at 02:22:23PM -0700, David Fetter wrote:
> On Fri, Oct 07, 2005 at 08:21:31PM -0500, Jim C. Nasby wrote:
> > On Fri, Oct 07, 2005 at 02:07:47AM -0700, David Fetter wrote:
> > > On Fri, Oct 07, 2005 at 11:47:26AM +0300, WireSpot wrote:
> > > > But... will the resulting dump be consistent as far as foreign
> > > > keys are concerned? Or will the current -t warning still apply
> > > > (YMMV as to the consistency of the resulting dump)?
> > >
> > > I think the latter is better.  This is solidly in the realm of
> > > prying off cover plates, and the warning is already there :)
> >
> > I think it would be good to include an option that only does
> > checking and doesn't actually try to dump anything. That would make
> > it easier to ensure your config file is correct.
>
> Could you flesh this out a bit?  What would this option produce in the
> (imho most common) case where dependencies weren't all taken care of?

For one thing, it would produce a list of missing dependancies (or any
other errors that could be detected without doing the actual dump, for
that matter).  I think that when trying to setup a non-trival dump
scenario, it would be great to actually produce output stating exactly
what dump would have done had it run for real. One way to think of it
would be running pg_dump -v and piping stdout to /dev/null.
--
Jim C. Nasby, Sr. Engineering Consultant      jnasby@pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461

pgsql-general by date:

Previous
From: David Fetter
Date:
Subject: Re: Dump all except some tables?
Next
From: Matthew Terenzio
Date:
Subject: Re: Oracle buys Innobase