Ed Loehr <eloehr@austin.rr.com> writes:
> How would you handle multi-column indices that included the column
> being dropped? E.g.,
> create unique index foobar on mytable(foo,bar);
> where the 'bar' column is then dropped...
Good question, but I don't think we had an answer for it in the other
scheme either.
In Hiroshi's scheme it seems like it might "just work" anyway: the index
would still be there, it'd just start filling with all nulls in the bar
column. AFAIR, a unique index won't complain about that under SQL92
rules.
On the whole it might be better to refuse to do the DROP COLUMN until
the user gets rid of such an index. It would certainly be wrong for
us to try to replace the index withcreate unique index foobar on mytable(foo);
since the original index did *not* imply uniqueness on foo alone.
Similarly, I'd be very strongly inclined to punt if we find any
constraints that mention both the target column and other columns.
We cannot fix those automatically, and silently dropping them doesn't
sound good either. Make the user do something with them, instead.
regards, tom lane