Re: Dump all except some tables?

From: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>
To: David Fetter <david(at)fetter(dot)org>
Cc: WireSpot <wirespot(at)gmail(dot)com>, Roger Hand <RHand(at)kailea(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-general(at)postgresql(dot)org
Subject: Re: Dump all except some tables?
Date: 2005-10-08 22:33:16
Message-ID: 20051008223316.GA36108@pervasive.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Mitch Pirtle 2005-10-08 23:35:11 Re: Oracle buys Innobase
Previous Message Matthew Terenzio 2005-10-08 22:26:55 Re: Oracle buys Innobase