From: | "Glen Parker" <glenebob(at)nwlink(dot)com> |
---|---|
To: | <pgsql-general(at)postgresql(dot)org> |
Subject: | Dropping column silently kills multi-coumn index (was [ODBC] Error when accessing tables with deleted columns) |
Date: | 2003-01-29 22:47:04 |
Message-ID: | 02a501c2c7e8$5d6fe6f0$0b01a8c0@saturn |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-odbc |
The other discussion made me try this out:
> So the new dll did take out the delete column. I
> assume that if you do a drop column that it removes
> the associated index.
(Obviously 7.3.* is involved here...)
I did the following:
oms=# create table __temp1(field1 varchar(10), field2 varchar(10));
CREATE TABLE
oms=# create index __idx_temp1 on __temp1 (field1, field2);
CREATE INDEX
oms=# alter table __temp1 drop column field2;
ALTER TABLE
Note that the ALTER TABLE query succeeded *quietly* and did in fact drop
the index.
Is this intended behavior? Rather seems like it should refuse to drop
an indexed column, or at least refuse to drop a culumn that's a member
of a multi-culumm index and give notice when an index is dropped. I
think I'd opt for the never-drop-an-indexed-column approach.
Just an observation :-)
Glen Parker
glenebob(at)nwlink(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | John Smith | 2003-01-29 23:00:16 | mass import to table with unique index |
Previous Message | Nigel J. Andrews | 2003-01-29 22:30:49 | Perl DBI and placeheld values |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-01-29 23:33:01 | Re: Dropping column silently kills multi-coumn index (was [ODBC] Error when accessing tables with deleted columns) |
Previous Message | Michael Calabrese | 2003-01-29 22:19:51 | Re: Error when accessing tables with deleted columns |