amul sul writes:
> 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?
It's not built-in. It's installed by default, yes, but it's also
droppable.
On 31 Oct 2016 6:48 pm, "Tom Lane" wrote:
>
> amul sul writes:
> > On Fri, Oct 28, 2016 at 6:22 PM, Robert Haas
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 de
amul sul writes:
> On Fri, Oct 28, 2016 at 6:22 PM, Robert Haas 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
On Fri, Oct 28, 2016 at 6:22 PM, Robert Haas wrote:
> On Thu, Oct 27, 2016 at 2:11 AM, amul sul 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 install
On Thu, Oct 27, 2016 at 2:11 AM, amul sul 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
> ?
There's a comment
Hi
,
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
?
Thanks
&
Regards,
Amul
