Petr Jelinek <petr@2ndquadrant.com> writes:
> On 09/11/14 23:36, Petr Jelinek wrote:
>> On 09/11/14 23:04, Tom Lane wrote:
>>> I suspect this is actually a bug in the dependency search logic in DROP.
>>> Don't have the energy to chase it right now though.
>> But this logic depends on the fact that the columns that belong to that
>> table are processed after the table was already processed, however as
>> the new type was added after the table was added, it's processed before
>> the table and because of the dependency between type and columns, the
>> columns are also processed before the table and so they are added to the
>> object list for further dependency checking.
Yeah. We had code to handle the table-visited-before-column case, but
for some reason not the column-visited-before-table case. Rather odd
that this hasn't been reported before.
> So here is what I came up with to fix this. It's quite simple and works
> well enough, we don't really have any regression test that would hit
> this though.
This is incomplete. stack_address_present_add_flags needs a similar fix,
and both of them need to be taught to deal with the possibility that more
than one such column is present (I don't think your "continue" quite works
for that). 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.
Will work on this. Thanks for the report and test case!
regards, tom lane
