Re: Dropping column silently kills multi-coumn index
От | Lincoln Yeoh |
---|---|
Тема | Re: Dropping column silently kills multi-coumn index |
Дата | |
Msg-id | 5.1.0.14.1.20030215171101.02d50090@mbox.jaring.my обсуждение исходный текст |
Ответ на | Re: Dropping column silently kills multi-coumn index (was (Justin Clift <justin@postgresql.org>) |
Ответы |
Re: Dropping column silently kills multi-coumn index (was
|
Список | pgsql-general |
At 11:36 AM 2/15/03 +1100, Justin Clift wrote: >Bruce Momjian wrote: >>think CASCASE enters into this because of the effect on field1. >>Comments? > >Would it be possible/practical to have PostgreSQL recreate the >multi-column index, but without the dropped column? Wouldn't that take a long time in some cases? I think it's a good idea to throw an error and refuse to drop the column and index and let the DB admin decide what to do next. If someone designs a system that regularly drops columns from tables AND wants indexes on those columns, I'd figure requiring them to drop relevant indexes first would be a good idea. Of course if they can optionally configure things (triggers etc) to drop the index when dropping/altering a column, that would be ok too. When the admins don't know what they are doing or make a mistake - it'll fail safe. When the admins know, as long as they are still able to set things up accordingly, I don't think it's a big problem. Regards, Link.
В списке pgsql-general по дате отправления: