Re: Query regarding selectDumpableExtension()

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