From: | Dan Armbrust <daniel(dot)armbrust(dot)list(at)gmail(dot)com> |
---|---|
To: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: fine tuned database dump/reload? |
Date: | 2005-10-14 15:24:55 |
Message-ID: | 434FCDC7.5010609@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Jim C. Nasby wrote:
> Since no one else has mentioned it, there has been discussion this week
> on one of the lists (probably -general or -hackers) about expanding the
> capabilities of pg_dump. I've advocated for allowing a file that
> specifies what objects to dump and what kind of filtering to apply to
> the name. Allowing for only dumping certain rows in a table (applying a
> WHERE clause) would be a neat addition to that.
That would be exactly what I need - the ability to apply a where clause.
That - and the ability to specify multiple tables to dump, instead of
just one.
Because currently, I still get into foreign key trouble in this scenario:
I drop data (and only data) from database A. This data has foreign key
constraints. I want to load this data into database B - where the
tables already exist, they already have foreign keys, and there is some
existing data.
My dump from database A won't load - because the tables were dumped in
the wrong order to satisfy the foreign keys on the reload - so the only
way I can load this data back into an existing database is to dump each
table individually, and reload in the proper order, or manually drop my
foreign keys while I load the data.
Both ways are a pain - and it makes it overly difficult to export/import
chunks of data from a database.
Dan
--
****************************
Daniel Armbrust
Biomedical Informatics
Mayo Clinic Rochester
daniel.armbrust(at)mayo.edu
http://informatics.mayo.edu/
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Sullivan | 2005-10-14 15:48:39 | Re: On "multi-master" |
Previous Message | Scott Marlowe | 2005-10-14 15:20:41 | Re: On "multi-master" |