From: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com> |
---|---|
To: | Dan Armbrust <daniel(dot)armbrust(dot)list(at)gmail(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: fine tuned database dump/reload? |
Date: | 2005-10-15 23:28:00 |
Message-ID: | 20051015232800.GE86144@pervasive.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
pg_dump handles table ordering properly.
On Fri, Oct 14, 2005 at 10:24:55AM -0500, Dan Armbrust wrote:
> 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/
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
>
--
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
From | Date | Subject | |
---|---|---|---|
Next Message | Jim C. Nasby | 2005-10-15 23:34:00 | Re: [pgsql-advocacy] Oracle buys Innobase |
Previous Message | Peter Eisentraut | 2005-10-15 22:19:11 | Re: PostgreSQL Gotchas |