Re: Cascaded Column Drop

Bruce Momjian dijo:

> Tom Lane wrote:
> > Rod Taylor <rbt@rbt.ca> writes:
> > > When a cascaded column drop is removing the last column, drop the table
> > > instead.  Regression tests via domains.
> >
> > Is that a good idea, or should we refuse the drop entirely?  A table
> > drop zaps a lot more stuff than a column drop.
>
> I think we should refuse the drop.  It is just too strange.  You can
> suggest if they want the column dropped, just drop the table.

Yeah... you can't have triggers, you can't have constraints.  Hey, you
can create a view using it, and possibly you can inherit the table...
but what's that good for?

But think about the inheritance case again: suppose

create table p (f1 int);
create table c (f2 int) inherits (p);

Now you just change your mind and want to drop p but not c.  You can't
do it because f1 is the last column on it, and c inherits it.  So a way
to drop the last column inherited (thus freeing the dependency on p)
makes c independent, and you can drop p.

But note that this drop of p is not just drop-cascade: the inheritance
tree has to get out of the dependency info first (it's not drop-restrict
either, is it?)

--
Alvaro Herrera (<alvherre[a]atentus.com>)
"La espina, desde que nace, ya pincha" (Proverbio africano)