From: | Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com> |
---|---|
To: | Max Khon <mkhon(at)swsoft(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: ON DELETE CASCADE with multiple paths |
Date: | 2007-05-21 15:52:56 |
Message-ID: | 20070521084334.I64869@megazone.bigpanda.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Mon, 21 May 2007, Max Khon wrote:
> Stephan Szabo wrote:
> > On Thu, 17 May 2007, Tom Lane wrote:
> >
> >> Max Khon <mkhon(at)swsoft(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Zdenek Kotala | 2007-05-21 17:43:55 | Re: BUG #3291: Query tool not returning all results |
Previous Message | Zdenek Kotala | 2007-05-21 11:46:41 | Re: BUG #3291: Query tool not returning all results |