On 31 Oct 2016 6:48 pm, "Tom Lane" <t...@sss.pgh.pa.us> wrote: > > amul sul <sula...@gmail.com> writes: > > On Fri, Oct 28, 2016 at 6:22 PM, Robert Haas <robertmh...@gmail.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.
