Re: Foreign keys for non-default datatypes
От | Michael Paesold |
---|---|
Тема | Re: Foreign keys for non-default datatypes |
Дата | |
Msg-id | 031d01c63fa2$0b457130$67dc8380@zaphod обсуждение исходный текст |
Ответ на | Foreign keys for non-default datatypes (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Tom Lane writes: > "Michael Paesold" <mpaesold@gmx.at> writes: >> Will this trigger still be called, so it can abort the delete? > > We'd certainly still call triggers and check row-level constraints, > and any error would abort the whole statement (leaving A unmodified). > > The case that I think we'd forbid if the implementation could support > doing so is where a BEFORE trigger cancels the B-update operation by > returning NULL. This currently leaves you with a row in B that violates > the FK constraint (once the A row is gone). > > Triggers that modify the row to be stored are not a problem, because > B will have an AFTER trigger that rechecks the row against A anyway. > AFAICS it's only the silent-cancellation case that subverts RI > constraints. > > Rules on B that rewrite the DELETE or UPDATE into something else are > also problematic. > > This is all moot at the moment since Stephan pointed out that we still > need planning for the FK actions (ie the cascaded deletes/updates). > So I'm not currently thinking of redoing the implementation of actions. Ok, thank you for the explanation. At least I am not worried about a future reimplementation of the RI triggers. Best Regards, Michael Paesold
В списке pgsql-hackers по дате отправления: