Re: DROP VIEW code question

Поиск
Список
Период
Сортировка
Искать
От
Tom Lane
Тема
Re: DROP VIEW code question
Дата
Msg-id
2219.971815421@sss.pgh.pa.us
Ответ на
Re: DROP VIEW code question (Peter Eisentraut)
Список
Дерево обсуждения
DROP VIEW code question Mark Hollomon <mhh@mindspring.com>
Re: DROP VIEW code question Tom Lane <tgl@sss.pgh.pa.us>
Re: DROP VIEW code question Mark Hollomon <mhh@mindspring.com>
Re: DROP VIEW code question Peter Eisentraut <peter_e@gmx.net>
Re: DROP VIEW code question Tom Lane <tgl@sss.pgh.pa.us>
Peter Eisentraut  writes:
> I don't know how it looks now, but the "DROP TABLE x, y, z" was pretty
> broken a while ago.  For example, if there was some sort of dependency
> between the tables (foreign keys?) it would abort and leave an
> inconsistent state.  I'm not very fond of this extension, but keep the
> issue in mind.

This is just a special case of the generic problem that you can't
roll back a DROP TABLE.  That'll be fixed by 7.1, so I see no reason
not to allow the more convenient syntax.

BTW, Mark, the reason utility.c implements T_DropStmt with two loops
is presumably to try to avoid the rollback-drop-table problem; but it's
inherently bogus because not all error conditions can be checked there.
You could fold the two loops into one loop, and/or remove any checks
that are redundant with RemoveRelation itself.
		regards, tom lane

В списке pgsql-hackers по дате отправления
От: Tom Lane
Дата:
Сообщение: Re: DROP VIEW code question
От: Tatsuo Ishii
Дата:
FAQ