Re: Dump all except some tables?

Поиск
Список
Период
Сортировка
От Jim C. Nasby
Тема Re: Dump all except some tables?
Дата
Msg-id 20051008223316.GA36108@pervasive.com
обсуждение исходный текст
Ответ на Re: Dump all except some tables?  (David Fetter <david@fetter.org>)
Список 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 по дате отправления:

Предыдущее
От: David Fetter
Дата:
Сообщение: Re: Dump all except some tables?
Следующее
От: Matthew Terenzio
Дата:
Сообщение: Re: Oracle buys Innobase