Re: Query regarding selectDumpableExtension()

On Fri, Oct 28, 2016 at 6:22 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Thu, Oct 27, 2016 at 2:11 AM, amul sul <sulamul@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