Re: Dropping column silently kills multi-coumn index (was
От | Bruce Momjian |
---|---|
Тема | Re: Dropping column silently kills multi-coumn index (was |
Дата | |
Msg-id | 200302151829.h1FITtX28683@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: Dropping column silently kills multi-coumn index (Lincoln Yeoh <lyeoh@pop.jaring.my>) |
Ответы |
Re: Dropping column silently kills multi-coumn index (was
|
Список | pgsql-general |
Added to TODO: * Disallow DROP COLUMN on a column that is part of a multi-column index --------------------------------------------------------------------------- Lincoln Yeoh wrote: > 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. > > > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
В списке pgsql-general по дате отправления: