Re: Dropping column silently kills multi-coumn index (was [ODBC] Error when accessing tables with deleted columns)
От | Glen Parker |
---|---|
Тема | Re: Dropping column silently kills multi-coumn index (was [ODBC] Error when accessing tables with deleted columns) |
Дата | |
Msg-id | 02a901c2c7f8$8f67da40$0b01a8c0@saturn обсуждение исходный текст |
Ответ на | Dropping column silently kills multi-coumn index (was [ODBC] Error when accessing tables with deleted columns) ("Glen Parker" <glenebob@nwlink.com>) |
Ответы |
Re: Dropping column silently kills multi-coumn index (was
|
Список | pgsql-general |
> > 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
В списке pgsql-general по дате отправления: