Re: [HACKERS] DROP COLUMN round 4

"Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au> writes:
> 1. It cascade deletes objects, but it _always_ cascades, no matter what
> behaviour I specify. Also, it doesn't give me indications that
> it's cascade deleted an object.
>>
>> Would you give a specific example?

> [ dropping a column silently drops an index on the column ]

This happens because indexes are marked DEPENDENCY_AUTO on their
columns. The drop will cascade to the index even under RESTRICT;
if you have message level set to DEBUG1 or higher you'll be told
about it, but otherwise the behavior is to zap the index quietly.

An example of a case where RESTRICT should make a difference is
where you have a foreign key reference from another table, or
a view that uses the column you're trying to delete.

We can debate whether indexes ought to be AUTO dependencies or not.
It seems reasonable to me though. Indexes aren't really independent
objects to my mind, only auxiliary thingummies...

>> AlterTableDropColumn neglects to heap_close the relation, but I'm
>> surprised that error isn't reported sooner.

> Fixed. New diff attached - fixes regression tests as well, plus re-merged
> against HEAD.

Thanks, will work from this.

> Note that the check against the parent attribute when adding a foreign key
> probably should be improved. ie. It relies on the fact that the parent
> column(s) should not have a unique index on them (thanks to dependencies),
> rather than actually checking the attisdropped attribute.

Uh ... maybe it's too late at night here, but I didn't follow.

regards, tom lane