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  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] DROP COLUMN round 4
Следующее
От: Thomas Lockhart
Дата:
Сообщение: Re: int64 timestamp patch for contrib/pg_controldata