I wrote:
> Jim Nasby writes:
>> On 12/1/16 1:09 PM, Tom Lane wrote:
>>> I think that the patch I wrote is good cleanup, so I'm still inclined
>>> to apply it in HEAD, but I no longer think it's fixing any case that's
>>> significant in the field. I wonder if you have a counterexample?
>> No; I'm
Jim Nasby writes:
> On 12/1/16 1:09 PM, Tom Lane wrote:
>> I think that the patch I wrote is good cleanup, so I'm still inclined
>> to apply it in HEAD, but I no longer think it's fixing any case that's
>> significant in the field. I wonder if you have a counterexample?
> No; I'm sure I've run i
On 12/1/16 1:09 PM, Tom Lane wrote:
I think that the patch I wrote is good cleanup, so I'm still inclined
to apply it in HEAD, but I no longer think it's fixing any case that's
significant in the field. I wonder if you have a counterexample?
No; I'm sure I've run into this because of a temp ob
I wrote:
>> Jim Nasby writes:
>>> I can't think of any reason you'd want the current behavior.
>> But I think fixing it to not recurse to extensions during temp namespace
>> cleanup might not be very hard. I'll take a look.
I wrote a test case to try to demonstrate that this patch was fixing a
I wrote:
> Jim Nasby writes:
>> I can't think of any reason you'd want the current behavior.
> But I think fixing it to not recurse to extensions during temp namespace
> cleanup might not be very hard. I'll take a look.
Here's a draft patch for that. Rather than sticking yet another special
as
Jim Nasby writes:
> On 11/27/16 10:15 AM, Tom Lane wrote:
>> Yeah, I was wondering about that yesterday --- that comment mentions
>> the case of temporary objects, but it only fixes the problem while the
>> script runs. Maybe there should be a separate test for "we're doing
>> temporary-object cl
On 11/27/16 10:15 AM, Tom Lane wrote:
Jim Nasby writes:
I suspect this is unrelated, but I've run into another oddity with
extension dependency: if an extension creates any temporary objects the
extension will install and function correctly... until the backend that
created the extension quits.
Jim Nasby writes:
> I suspect this is unrelated, but I've run into another oddity with
> extension dependency: if an extension creates any temporary objects the
> extension will install and function correctly... until the backend that
> created the extension quits. This is VERY confusing if you
On 11/26/16 10:25 AM, Tom Lane wrote:
It suddenly struck me that the problem being complained of in bug #14434
is that dependency.c's findDependentObjects() is handling extension
dependencies incorrectly.
I suspect this is unrelated, but I've run into another oddity with
extension dependency:
It suddenly struck me that the problem being complained of in bug #14434
is that dependency.c's findDependentObjects() is handling extension
dependencies incorrectly. It has this logic:
/*
* This object is part of the internal implementation of
*
10 matches
Mail list logo
