Re: Foreign key trigger timing bug? - Mailing list pgsql-hackers

From Jan Wieck
Subject Re: Foreign key trigger timing bug?
Date
Msg-id 4399AEAF.4030301@Yahoo.com
Whole thread Raw
In response to Re: Foreign key trigger timing bug?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Foreign key trigger timing bug?
List pgsql-hackers
On 12/8/2005 8:53 PM, Tom Lane wrote:

> Stephan Szabo <sszabo@megazone.bigpanda.com> writes:
>> Yeah.  I really don't understand it, but it appears to me to be explicitly
>> different in the spec for on delete cascade even compared to the rest of
>> the referential actions.
> 
>>> One problem I see is, what do we do if the BEFORE
>>> trigger then returns NULL (to skip the delete). The cascaded operations
>>> are already done. Do we have to execute the cascaded deletes in a
>>> subtransaction or do we disallow the skip in this case?
> 
>> I think we'd have disallow skipping.  Especially since skipping would
>> probably end up with a violated constraint.
> 
> That seems to me to be a sufficient reason to not follow the spec in
> this respect.  A BEFORE trigger should be run BEFORE anything happens,
> full stop.  I can't think of any good reason why the spec's semantics
> are better.  (It's not like our triggers are exactly spec-compatible
> anyway.)

It doesn't lead to a violated constraint. bar references foo on delete 
cascade, now delete from foo will first delete from bar, then the before 
trigger on foo skips the delete.

And besides, as the other post (Trigger preventing delete causes 
circumvention of FK) in GENERAL shows, triggers can break RI anyway.


Jan

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Warm-cache prefetching
Next
From: "Ricardo Vaz - TCESP"
Date:
Subject: Log of CREATE USER statement