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

Re: TODO: DROP COLUMN .. CASCADE

From: Antti Haapala <antti(dot)haapala(at)iki(dot)fi>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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 18:30:57
Message-ID: Pine.LNX.4.44.0303062009500.8975-100000@lastu2.oulu.fi (view raw or flat)
Thread:
Lists: pgsql-hackers
On Thu, 6 Mar 2003, Bruce Momjian wrote:

> Tom Lane wrote:
> > 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.
>
> I do see the confusion argument, but I also see cases where folks are
> losing the use of an index for single-column lookups.  Others?

If I had table x:

create table dev (
	major int,
	minor int
);

and I CREATEd UNIQUE INDEX ON dev(major,minor), and then dropped col
minor, postgresql would silently create a new index on dev(major), or even
worse, use the existing index which has satellite data haunting from
minor? That would really be strange.

What if I noticed that I need to change type of b to int8 in the early
design stages? I drop col b and then add again col b with type int8, and
CREATE new UNIQUE INDEX ON dev(major, minor). Perhaps I don't even notice
that I have (redundant) index still on major, which only eats CPU time and
disk space.

-- 
Antti Haapala


In response to

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2003-03-06 18:40:01
Subject: Re: TODO: DROP COLUMN .. CASCADE
Previous:From: Rod TaylorDate: 2003-03-06 18:13:28
Subject: Re: TODO: DROP COLUMN .. CASCADE

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