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