Re: Bug #759: 7.3beta1 DROP COLUMN DEPENDENCY PROBLEM

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 <rbt(at)zort(dot)ca> 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.
>