From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Rod Taylor <rbt(at)rbt(dot)ca>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: TODO: DROP COLUMN .. CASCADE |
Date: | 2003-03-06 17:25:48 |
Message-ID: | 16875.1046971548@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Tom Lane wrote:
>> Personally I'm not sold on the sensefulness of the TODO item to begin
>> with.
> The current code just drops any index that inludes the dropped column,
> even if the column is the second column in a multi-column index. Does
> that seem OK to you?
What's wrong with it? Any unique constraint the index might have
carried is no longer interesting, so there's no semantic reason for
treating the index as an independent object. And queries that might
have referenced the column aren't going to work anymore, so the query
mix changes and hence the index setup will really need rethinking anyhow.
Basically I think this proposal would introduce a weird, confusing
dichotomy of behavior between single- and multi-column indexes.
And as Rod pointed out, you'd logically have to do the same for CHECK
constraints depending on whether they mention one or several columns.
(And what of multicolumn foreign keys?) I see much confusion ahead,
and no payback.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2003-03-06 18:01:17 | Re: TODO: DROP COLUMN .. CASCADE |
Previous Message | Bruce Momjian | 2003-03-06 17:15:50 | Re: TODO: DROP COLUMN .. CASCADE |