Re: Column/type dependency recording inconsistencies

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.

regards, tom lane