Re: TODO: DROP COLUMN .. CASCADE
От | Bruce Momjian |
---|---|
Тема | Re: TODO: DROP COLUMN .. CASCADE |
Дата | |
Msg-id | 200303061801.h26I1HJ11513@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: TODO: DROP COLUMN .. CASCADE (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: TODO: DROP COLUMN .. CASCADE
Re: TODO: DROP COLUMN .. CASCADE |
Список | pgsql-hackers |
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.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. 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? -- 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, Pennsylvania19073
В списке pgsql-hackers по дате отправления: