Re: db partial dumping with pg_dump

From: Scott Shattuck <ss(at)technicalpursuit(dot)com>
To: Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>, Rod Taylor <rbt(at)zort(dot)ca>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: db partial dumping with pg_dump
Date: 2002-08-14 02:29:47
Message-ID: 1029292188.7491.3851.camel@idearat
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 2002-08-13 at 19:54, Christopher Kings-Lynne wrote:
> > I'm finding it hard to visualize situations where I'd want the extra
> > baggage of pg_dump for something like this. If I want the schema at
> > all, I'll probably want it separate from the data so that I can hack
> > the schema conveniently --- so I'd want to do a "pg_dump -s -t table"
> > and then do the selective copying separately.
>
> Tell you what I'd kill for:
>
> pg_dump -t users_\* db > users.sql
>
> Sort of thing.
>
> Chris
>

I'd kill for pg_restore --ignore-missing-objects --clean .... so I could
run refreshes against databases that are changing schemas rather than
having to constantly edit the output of -l.

I'd also kill for pg_restore --ignore-existing-objects .... so I could
run the darn thing against a database that's already got pl/pgsql
installed in template1 and the dump file wants to install it again etc.

ss

>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hannu Krosing 2002-08-14 02:42:49 Re: Open 7.3 items
Previous Message Marc G. Fournier 2002-08-14 02:07:14 Re: [COMMITTERS] pgsql-server/src backend/tcop/postgres.cbacke