From: | Lincoln Yeoh <lyeoh(at)pop(dot)jaring(dot)my> |
---|---|
To: | Justin Clift <justin(at)postgresql(dot)org>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Glen Parker <glenebob(at)nwlink(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Dropping column silently kills multi-coumn index |
Date: | 2003-02-15 09:19:53 |
Message-ID: | 5.1.0.14.1.20030215171101.02d50090@mbox.jaring.my |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Tony Grant | 2003-02-15 14:23:17 | Re: Just installed using Fink on OS X. Fails all over |
Previous Message | Mario Weilguni | 2003-02-15 09:15:41 | Re: In 7.3.1, will I be able to reindex toast? |