Re: fine tuned database dump/reload? - Mailing list pgsql-general

From Jim C. Nasby
Subject Re: fine tuned database dump/reload?
Date
Msg-id 20051015232800.GE86144@pervasive.com
Whole thread Raw
In response to Re: fine tuned database dump/reload?  (Dan Armbrust <daniel.armbrust.list@gmail.com>)
Responses Re: fine tuned database dump/reload?
List 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@pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461

pgsql-general by date:

Previous
From: Franz.Rasper@izb.de
Date:
Subject: Question/problem with create view and restore a backup with such a view
Next
From: "Jim C. Nasby"
Date:
Subject: Re: [pgsql-advocacy] Oracle buys Innobase