Re: Query regarding selectDumpableExtension() - Mailing list pgsql-hackers

From amul sul
Subject Re: Query regarding selectDumpableExtension()
Date
Msg-id CAAJ_b97jh3Y-SUTOdvHABt7HGEpwskx-2TTuWCAAChVTCzKOwQ@mail.gmail.com
Whole thread Raw
In response to Re: Query regarding selectDumpableExtension()  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Query regarding selectDumpableExtension()  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: add more NLS to bin
Next
From: Albe Laurenz
Date:
Subject: Re: sequential scan result order vs performance