Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2003-03-06 18:01:17
Subject: Re: TODO: DROP COLUMN .. CASCADE
Previous:From: Bruce MomjianDate: 2003-03-06 17:15:50
Subject: Re: TODO: DROP COLUMN .. CASCADE

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group