On Fri, 19 Aug 2005, Stephan Szabo wrote:
> On Fri, 19 Aug 2005, Tom Lane wrote:
>
> > Stephan Szabo <[EMAIL PROTECTED]> writes:
> > > Is the correct answer to continue marking and running the triggers until
> > > there are no immediate triggers left to run for this case?
> >
> > Hmm ... my recollection is that we put in the concept of marking because
> > we needed it for correct behavior in some cases. I don't recall exactly
> > why though.
>
Hmm, there's an issue with before triggers as well. We add the checks for
the updates to the end of the current statement's queue and shouldn't run
them until all the cascaded updates are done. However, if a before on
update trigger of the fk side also updates an fk row that is in the middle
of a series of these updates with a direct update statement, that
statement's check will happen inside the before trigger, which will fail.
It's not necessarily a triggered data change violation if the change
happens to not change the key values or sets them to what the have already
or will become. We could get around this by somehow inheriting the state
of our direct parent trigger (whether or not it was in a new query), but
that seems like it'd break other cases because the triggers would line up
in the pre-8.0 sequence in that case. Or, is it correct to fail in this
case because the statement is trying to update in a new query to a set of
invalid keys?
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
