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 tables from 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 where existing objects dependent on it. The
restore threw the HINT and a subsequent ERROR over trying to CREATE
SCHEMA public where 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 way to 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 order of
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