Re: ON DELETE CASCADE with multiple paths
От | Stephan Szabo |
---|---|
Тема | Re: ON DELETE CASCADE with multiple paths |
Дата | |
Msg-id | 20070521084334.I64869@megazone.bigpanda.com обсуждение исходный текст |
Ответ на | Re: ON DELETE CASCADE with multiple paths (Max Khon <mkhon@swsoft.com>) |
Ответы |
Re: ON DELETE CASCADE with multiple paths
|
Список | pgsql-bugs |
On Mon, 21 May 2007, Max Khon wrote: > Stephan Szabo wrote: > > On Thu, 17 May 2007, Tom Lane wrote: > > > >> Max Khon <mkhon@swsoft.com> writes: > >>> "delete from foo" fails: > >>> ERROR: update or delete on table "bar" violates foreign key constraint > >>> "foobar_fk0" on table "foobar" > >>> SQL state: 23503 > >>> Detail: Key (bar_id)=(1) is still referenced from table "foobar". > >>> Context: SQL statement "DELETE FROM ONLY "public"."bar" WHERE "foo_id" = $1" > >> I see no bug here. There is no guarantee about the order in which > >> constraints are applied. > > > > Except that SQL92 at least does seem to say in 11.8 that "All rows that > > are marked for deletion are effectively deleted at the end of the > > SQL-statement, prior to the checking of any integrity constraints." I > > think that likely makes our behavior wrong, but I'm not really sure how to > > get there from what we have now. > > Is it sufficient to execute ON DELETE CASCADE and ON DELETE SET > NULL/DEFAULT triggers before other triggers? Hmm, I'm not sure. I'm not sure if that's sufficient and that it doesn't add any holes, but we can check that. At least I think on set default triggers we'd need to do something with the check performed from inside the trigger.
В списке pgsql-bugs по дате отправления: