Re: Column/type dependency recording inconsistencies

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.
>>
>
> Yes that's where I started searching also and yes it is. The actual
> situation is that the columns of the table that is about to be dropped
> are normally not added to the object list that is used for dependency
> checks (if the table is going to be dropped who cares about what column
> depends on anyway).
> 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.
>
> See use and source of object_address_present_add_flags in dependency.c.
>

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.

I wonder if the object_address_present_add_flags should be renamed since
it does bit more than what name suggests at this point.

And I think this should be backpatched to all the versions with
extension support.

--
  Petr Jelinek                  http://www.2ndQuadrant.com/
  PostgreSQL Development, 24x7 Support, Training & Services