Re: [HACKERS] DROP COLUMN round 4

> "Christopher Kings-Lynne" <chriskl@familyhealth.com.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?

test=# create table test (a int4, b int4);
CREATE TABLE
test=# create index temp on test (a);
CREATE INDEX
test=# \dt
        List of relations
 Name | Schema | Type  |  Owner
------+--------+-------+---------
 test | public | table | chriskl
(1 row)

test=# \di
            List of relations
 Name | Schema | Type  |  Owner  | Table
------+--------+-------+---------+-------
 temp | public | index | chriskl | test
(1 row)

test=# alter table test drop a restrict;
ALTER TABLE
test=# \di
No relations found.
test=#

> > + drop table child;
> > + ERROR:  RelationForgetRelation: relation 143905 is still open
>
> > What's with the RelationForgetRelation error???  Am I not closing some
> > handle somewhere?
>
> 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.

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.

Chris