Re: TODO: DROP COLUMN .. CASCADE

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

In response to

Responses

Browse pgsql-hackers by date

  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