Re: fine tuned database dump/reload?

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

In response to

Responses

Browse pgsql-general by date

  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