On 11/11/14 21:47, Tom Lane wrote:
> I wrote:
>> ... Also, I find physically removing an entry fairly ugly and
>> possibly unsafe, since it's not clear what outer recursion levels might be
>> assuming about the contents of the array -- and that certainly won't work
>> for the stack case. What seems better is to invent another flag bit
>> to indicate that we no longer need to physically delete this subobject
>> because we've discovered the whole object will be deleted. Then we
>> can just skip it during the execution phase.
>
> On further reflection, neither of those approaches is really a good idea.
> With either implementation, skipping the DROP COLUMN step would mean that
> we're letting the DROP TYPE happen before we drop a table containing a
> live column of that type. While that failed to fail in this particular
> example, it sounds like a really bad idea --- any number of things, such
> as event triggers, could well blow up when abused like that. The lack of
> prior reports means that this is a very rare case, so rather than trying
> to "optimize" it, I think we should just let the drops happen in the
> scheduled order. All that we need is to make sure that the column gets
> marked with flags indicating that dropping is allowed. Accordingly, the
> attached patch should do it.
>
Yup, this patch seems to be much better and safer fix.
I can confirm that it works fine with both the test-case and my original
upgrade script. Thanks!
-- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training &
Services
