Thread: Cascaded Column Drop
When a cascaded column drop is removing the last column, drop the table instead. Regression tests via domains. Reported by Tim Knowles. -- Rod Taylor
Attachment
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.
What I was actually wondering about after reading Tim's report was
whether we could support zero-column tables, which would eliminate the
need for the special case altogether. I have not looked to see how
extensive are the places that assume tuples have > 0 columns ...
regards, tom lane
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. > What I was actually wondering about after reading Tim's report was > whether we could support zero-column tables, which would eliminate the > need for the special case altogether. I have not looked to see how > extensive are the places that assume tuples have > 0 columns ... Zero-width tables do sound interesting. Is it somehow non-relational? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian wrote: > Tom Lane wrote: >>What I was actually wondering about after reading Tim's report was >>whether we could support zero-column tables, which would eliminate the >>need for the special case altogether. I have not looked to see how >>extensive are the places that assume tuples have > 0 columns ... > > Zero-width tables do sound interesting. Is it somehow non-relational? > I can see a zero column table as a transition state maybe, but what else would they be useful for? Joe
Joe Conway wrote: > Bruce Momjian wrote: > > Tom Lane wrote: > >>What I was actually wondering about after reading Tim's report was > >>whether we could support zero-column tables, which would eliminate the > >>need for the special case altogether. I have not looked to see how > >>extensive are the places that assume tuples have > 0 columns ... > > > > Zero-width tables do sound interesting. Is it somehow non-relational? > > > > I can see a zero column table as a transition state maybe, but what else would > they be useful for? It's the /dev/null of the SQL world, but I'm not sure what that means. :-) -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
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)
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
>> What I was actually wondering about after reading Tim's report was
>> whether we could support zero-column tables, which would eliminate the
>> need for the special case altogether. I have not looked to see how
>> extensive are the places that assume tuples have > 0 columns ...
> Zero-width tables do sound interesting. Is it somehow non-relational?
Dunno. I wasn't really thinking that zero-width tables are all that
useful by themselves, but it does seem natural that you should be able
to redefine a column by
ALTER TABLE mytab DROP COLUMN foo;
ALTER TABLE mytab ADD COLUMN foo ...;
even if foo is the only column in mytab. Right now we reject that.
regards, tom lane
> > 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. Leaving a zero-width table would be best, even if its not so useful. I don't like rejecting a CASCADE as it kinda defeats the purpose of having CASCADE. The patch may not work right in complex cases anyway. It seems the switch to remove the table should be earlier. -- Rod Taylor
Alvaro Herrera <alvherre@atentus.com> writes:
> 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.
Hmm, no I don't think so. Parent-to-child dependence is a property of
the two tables, not of their columns, and should not go away just
because you reduce the parent to zero columns. I would expect that if
I dropped p.f1 (assuming this were allowed) and then added p.g1, that
c would also now have c.g1. So the parent/child relationship outlives
any specific column ... IMHO anyway.
regards, tom lane