Re: [HACKERS] DROP COLUMN round 4
От | Christopher Kings-Lynne |
---|---|
Тема | Re: [HACKERS] DROP COLUMN round 4 |
Дата | |
Msg-id | GNELIHDDFBOCMGBFGEFOAEHBCDAA.chriskl@familyhealth.com.au обсуждение исходный текст |
Ответ на | Re: [HACKERS] DROP COLUMN round 4 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] DROP COLUMN round 4
|
Список | pgsql-patches |
> This happens because indexes are marked DEPENDENCY_AUTO on their > columns. The drop will cascade to the index even under RESTRICT; > if you have message level set to DEBUG1 or higher you'll be told > about it, but otherwise the behavior is to zap the index quietly. Ah doh. I knew that as well. I'll try a view or something then... > > Note that the check against the parent attribute when adding a > foreign key > > probably should be improved. ie. It relies on the fact that the parent > > column(s) should not have a unique index on them (thanks to > dependencies), > > rather than actually checking the attisdropped attribute. OK, in this statement: ALTER TABLE child ADD FOREIGN KEY (a) REFERENCES parent(b); It does not check that column b is not dropped (it does check "a"). It just relies on the UNIQUE constraint not being present on b. This should probably be fixed... Chris
В списке pgsql-patches по дате отправления: