On Wed, 17 Aug 2005, Stephan Szabo wrote:
>
> On Tue, 16 Aug 2005, Stephan Szabo wrote:
>
> > On Tue, 16 Aug 2005, Tom Lane wrote:
> >
> > > I think this would take some generalization of afterTriggerInvokeEvents,
> > > which now might or might not find the target rel in the EState it's
> > > passed, but otherwise it doesn't seem too invasive. Thoughts?
> >
> > That doesn't seem too bad really, looking at afterTriggerInvokeEvents it
> > doesn't look like it'd be that much work to change it to handle that case.
> > I can put a patch together to see what it looks like.
>
> I did some work on this, and I'm getting a couple of other failures from
> other parts of the foreign key regression test (specifically an error
> that is no longer erroring in a multi-column on update set default). I'm
> going to need to look more closely to see if I can figure out why.
I think I see at least part of what's going on. It looks to me that
events are being added, but not fired because they weren't
marked. The event sequence seems to be:
after trigger begin query
add events for the actual statement
after trigger end query
fire trigger
add events for the triggered statement
finish trigger
skip event added for triggered statement because it's not marked.
Is the correct answer to continue marking and running the triggers until
there are no immediate triggers left to run for this case?
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
