On Fri, Oct 28, 2016 at 6:22 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Thu, Oct 27, 2016 at 2:11 AM, amul sul <sula...@gmail.com> wrote: >> selectDumpableExtension() function skip >> s dump of >> built-in extensions in case of binary-upgrade only, >> why not in normal >> dump >> ? >> Can't we assume those will already be installed in the target database >> at restore >> ? > Apologise for the delayed response.
> There's a comment in dumpExtension() that explains it. > > /* > * In a regular dump, we use IF NOT EXISTS so that there isn't a > * problem if the extension already exists in the target database; > * this is essential for installed-by-default extensions such as > * plpgsql. > * Understood. > * In binary-upgrade mode, that doesn't work well, so instead we skip > * built-in extensions based on their OIDs; see > * selectDumpableExtension. > */ > I don't see the necessity of dumping it in normal mode, unless I'm missing something. 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 Works well without '-c' option, but that what not a general solution, IMHO. Regards, Amul -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
