> > Note that the ALTER TABLE query succeeded *quietly* and did in fact
> > drop the index.
>
> If indexes require a CASCADE to be dropped by DROP COLUMN,
> then DROP TABLE on an indexed table would also require
> CASCADE. Does that seem like a good idea?
I see the connection you're trying to make there, but I don't think it
quite follows. When you drop a table, all its indexes logically become
orphaned and so can be quietly dropped; who would expect the indexes to
stay? When you drop a column that belongs to a multi-column index on
the other hand, the index does not become logically orphaned. It
becomes... Something else... I think it could be an intuative
expectation that the server should re-structure the index minus the
dropped field. In other words, the index *can* exist without the
dropped field, just not in its current form. Because of that
uncertainty, it makes sense to me to refuse to drop the column. The
reason I suggested the same behavior for *single* column indexes is
purely for constistancy.
The post that got me looking into this showed that exact uncertainty;
there was a question whether the index was dropped or not.
And no, requiring CASCADE on table drops to get rid of indexes makes
exactly zero sence to me :-)
Glen
