[prev in list] [next in list] [prev in thread] [next in thread] 

List:       postgresql-general
Subject:    Re: [GENERAL] Dropping column silently kills multi-coumn index (was [ODBC] Error when accessing tabl
From:       "Glen Parker" <glenebob () nwlink ! com>
Date:       2003-01-30 0:43:09
[Download RAW message or body]

> > Note that the ALTER TABLE query succeeded *quietly* and did in fact
> > drop the index.
> 
> If indexes require a CASCADE to be dropped by DROP COLUMN,
> then DROP TABLE on an indexed table would also require 
> CASCADE.  Does that seem like a good idea?

I see the connection you're trying to make there, but I don't think it
quite follows.  When you drop a table, all its indexes logically become
orphaned and so can be quietly dropped; who would expect the indexes to
stay?  When you drop a column that belongs to a multi-column index on
the other hand, the index does not become logically orphaned.  It
becomes... Something else...  I think it could be an intuative
expectation that the server should re-structure the index minus the
dropped field.  In other words, the index *can* exist without the
dropped field, just not in its current form.  Because of that
uncertainty, it makes sense to me to refuse to drop the column.  The
reason I suggested the same behavior for *single* column indexes is
purely for constistancy.

The post that got me looking into this showed that exact uncertainty;
there was a question whether the index was dropped or not.

And no, requiring CASCADE on table drops to get rid of indexes makes
exactly zero sence to me :-)

Glen


---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly
[prev in list] [next in list] [prev in thread] [next in thread]