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?

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