Re: Query regarding selectDumpableExtension()

On 31 Oct 2016 6:48 pm, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> 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.
>

Thanks for your explanation, I agree that this is not a single scenario
where we need special care, but still my question stands there, why do we
really need to dump built-in extension?

Of course you could ask, why not? And my answer will be same, "to placate
pg_restore at least in the case I've explained before" :)

Regards,
Amul
----------------------------------------------------------------------------------------------------
Sent from a mobile device. Please excuse brevity and tpyos.