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

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.

Best Regards,

Tim Knowles

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.