alter table cascade does not give notice about dropped indexes
Hi,
Looks like alter table does not tells about the indexes it dropped
PG version: 7.4.3
Regds
mallah.
tradein_clients=# \d general.membership_status
Table "general.membership_status"
+--------------------+-----------------------+------------------------+
| Column | Type | Modifiers |
+--------------------+-----------------------+------------------------+
| userid | integer | not null |
| profile_id | integer | not null |
| product_id | integer | not null |
| num_inq | integer | default 0 |
| listing | character varying(50) | |
| num_leads_featured | integer | default 0 |
| num_leads_pic | integer | default 0 |
| deleted | boolean | not null default false |
+--------------------+-----------------------+------------------------+
Indexes:
"user_profile_product_id" unique, btree (userid, profile_id,
product_id) WHERE (deleted IS FALSE)tradein_clients=#
tradein_clients=# ALTER TABLE general.membership_status drop column
profile_id cascade;
NOTICE: drop cascades to rule _RETURN on view active_membership_status
NOTICE: drop cascades to view active_membership_status
ALTER TABLE
Time: 992.921 ms
tradein_clients=# \d general.membership_status
Table "general.membership_status"
+--------------------+-----------------------+------------------------+
| Column | Type | Modifiers |
+--------------------+-----------------------+------------------------+
| userid | integer | not null |
| product_id | integer | not null |
| num_inq | integer | default 0 |
| listing | character varying(50) | |
| num_leads_featured | integer | default 0 |
| num_leads_pic | integer | default 0 |
| deleted | boolean | not null default false |
+--------------------+-----------------------+------------------------+tradein_clients=#
Rajesh Kumar Mallah <mallah@trade-india.com> writes:
Looks like alter table does not tells about the indexes it dropped
This is intentional --- we don't require you to say CASCADE to get rid
of an index, either. I don't recall the exact reasoning anymore, but
if you consult the mailing list archives (probably from the 7.3 beta
period) you can find the discussions that led up to doing it that way.
regards, tom lane
Tom Lane wrote:
Rajesh Kumar Mallah <mallah@trade-india.com> writes:
Looks like alter table does not tells about the indexes it dropped
This is intentional --- we don't require you to say CASCADE to get rid
of an index, either.
I initailly ran the alter table without cascade option ,
it told me there is a dependent view.
I did cascade , it droped the view and it also dropped a
multicolumn index that contained the column.
I notified me about the dropped view but not about
the index.
Is that ok ?
Regds
Mallah.
I don't recall the exact reasoning anymore, but
if you consult the mailing list archives (probably from the 7.3 beta
period) you can find the discussions that led up to doing it that way.regards, tom lane
--
regds
Mallah.
Rajesh Kumar Mallah
+---------------------------------------------------+
| Tradeindia.com (3,11,246) Registered Users |
| Indias' Leading B2B eMarketPlace |
| http://www.tradeindia.com/ |
+---------------------------------------------------+
Rajesh Kumar Mallah wrote:
Tom Lane wrote:
Rajesh Kumar Mallah <mallah@trade-india.com> writes:
Looks like alter table does not tells about the indexes it dropped
This is intentional --- we don't require you to say CASCADE to get rid
of an index, either.I initailly ran the alter table without cascade option ,
it told me there is a dependent view.
I did cascade , it droped the view and it also dropped a
multicolumn index that contained the column.I notified me about the dropped view but not about
the index.Is that ok ?
I think so. We consider the index to be bound to the table, while the
view is more distinct and could include other table references as well.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073