From: | Justin Clift <justin(at)postgresql(dot)org> |
---|---|
To: | 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 (was |
Date: | 2003-02-15 00:36:04 |
Message-ID: | 3E4D8B74.9030300@postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Bruce Momjian wrote:
> The issue here is whether dropping a column should automatically drop a
> multi-column index of which that column is a member.
>
> The example shown below is particularly good because the dropped field
> is second in the index, meaning that the index is useful for lookups on
> field1 alone, so dropping field2 removes a useful index on field1. I
> don't think it is defensible to allow DROP COLUMN to remove the index.
> Instead, I think we have to refuse the DROP COLUMN and require the user
> to drop the index and recreate it just on field1 if desired. I don't
> 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?
Regards and best wishes,
Justin Clift
--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
From | Date | Subject | |
---|---|---|---|
Next Message | Stephan Szabo | 2003-02-15 01:11:53 | Re: Lots o' I/O |
Previous Message | Tom Lane | 2003-02-15 00:33:33 | plpython trigger code is wrong (Re: Potential bug -- script that drops postgres server) |