From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | amul sul <sulamul(at)gmail(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Query regarding selectDumpableExtension() |
Date: | 2016-10-31 13:18:31 |
Message-ID: | 17322.1477919911@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
amul sul <sulamul(at)gmail(dot)com> writes:
> On Fri, Oct 28, 2016 at 6:22 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> There's a comment in dumpExtension() that explains it.
> Let me explain the case I'm trying to tackle. I have two old dump
> data, each of them have couple objects depend on plpgsql. I have
> restored first dump and trying restore second dump using 'pg_restore
> -c' command, it is failing with following error:
> ERROR: cannot drop extension plpgsql because other objects depend on it
This is hardly specific to extensions. If you try a restore with -c into
a database that has other random objects besides what's in the dump, you
could get errors from
* dropping tables that are referenced by foreign keys from tables not
known in the dump
* dropping functions that are used in views not known in the dump
* dropping operators or opclasses used by indexes not known in the dump
etc etc.
> Works well without '-c' option, but that what not a general solution, IMHO.
The general solution is either don't restore into a database containing
unrelated objects, or be prepared to ignore errors from the DROP commands.
The extension case actually works more smoothly than most of the others.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2016-10-31 13:21:19 | Re: Overlook in 2bd9e412? |
Previous Message | Robert Haas | 2016-10-31 13:09:43 | Re: Proposal : For Auto-Prewarm. |