Re: pg_restore - selective restore use cases. HINT use DROP CASCADE

Adrian.

Based on your earlier remarks and further investigation I find that the restoration of a schema ( -n ) goes smoothly if
thereare no foreign key 
References to the tables being restored from a schema that is not part of the restoration.  I had a couple of those
thatI had not initially appreciated and was able to redesign to accommodate that. 

Similarly if using the -t table restoration option of tables within a schema,  one has to include all tables that have
aforeign key reference to the table(s) being restored. I have to rethink some layout based on this but at least I
understandthis all now. 

I still think a drop cascade or defer constraints options might be useful.  I can probably pipe the pg_restore output
toa perl script that could "tweak" the pg_restore output and in turn pipe that to psql if I really need this
capability.

Thanks again for your assistance.

Dave



-----Original Message-----
From: Adrian Klaver [mailto:adrian.klaver@gmail.com]
Sent: Thursday, January 09, 2014 6:09 PM
To: Day, David; pgsql-general@postgresql.org
Subject: Re: [GENERAL] pg_restore - selective restore use cases. HINT use DROP CASCADE

On 01/09/2014 01:51 PM, Day, David wrote:
> Adrian,
>
> Thank you for your response.
>
> I would note that the original dump archive created by pg_dump
> included all schemas and that I only intend to restore a schema from it that is self contained, or a group of related
tablesfrom it. 

I just tried that here and succeeded. I did a pg_dump and then restored only the public schema which in this database
is self contained. I did get the HINT because I used the -c switch and it tried to drop the public schema and there
whereexisting objects dependent on it. The restore threw the HINT and a subsequent ERROR over trying to CREATE SCHEMA
publicwhere it already existed, but it completed the restore. 

>
> I acknowledge the dangers inherent in selective restoration, it just
> seems that a couple of additional options ( disable constraints, drop
> cascade ) to pg_restore would improve this utility to users who have
> put some thought into laying out the database design and failure cases from which they would like to recover.
>
> To have a pg_restore selective  restoration options, (-n, -t ), and
> have it fail simply because there are  foreign keys amongst the tables
> within that schema seems like to much protection or protection that I would at least like to have option to
over-ride.

We will probably need to see more detail on why that failed in your case because I did not see that in mine. Another
wayto influence the outcome is to use the -l and -L options to pg_restore. -l returns the -Fc dump file table of
contents(TOC)as a list. You can redirect that to a file and in that file comment out(using ;) items and rearrange the
orderof the TOC to suit your needs. Then you use pg_restore with the -L  option to feed it the edited TOC. 

http://www.postgresql.org/docs/9.3/interactive/app-pgrestore.html

>
> It may well be that I could shoot myself in the foot, but I'd still
> like to own the firearm :+)
>
>
> Regards
>
>
> Dave Day
>
>


--
Adrian Klaver
adrian.klaver@gmail.com