On Fri, 2002-09-06 at 10:07, Tim Knowles wrote: > Hi Guys, > > I haven't got access to my test machine which is at home so I can't try it > but will the previous practice of creating a temp table (minus the column > you want to delete), dropping the orignal and renaming the temp table work > in 7.3 or will the dependency check catch this when you try and drop the > orignal table too? If this is the case I'd imagine the route to take would > be to manually dump all the dependent views, drop those views, drop the > column and then recreate the views.
Yup.. Your going to have to drop all of the views, then the column. Or, ALTER TABLE ... DROP COLUMN .. CASCADE -- which will blow away the views for you. > On Fri, 2002-09-06 at 09:17, Tom Lane wrote: > > Rod Taylor <[EMAIL PROTECTED]> writes: > > > Indeed. At the INNER JOIN it would appear that an alias is applied to > > > the columns of a given table. > > > ... > > > The real trick is to make INNER JOINS less greedy in their requirements > > > based on the columns that are actually used. > > > > What surprised me about this report was not that the JOIN syntax exposed > > a dependency on column c, but that the non-JOIN syntax didn't. There > > shouldn't be any semantic difference AFAIR, so it seems to me that at > > least one of these behaviors needs to be fixed. > > > > I am not sure that it's practical to remove the dependency as Tim is > > hoping for... > > I wondered about that too, but by that time figured I was in way over my > head. > > The big difference is that the INNER JOIN code needs to drop one of the > colb's coming up with a virtual relation cola, colb, colc; where the > other doesn't have such a renaming scheme. > > Or, thats how it appears to function to the user. I've not dug into the > internals. > ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
