On Wed, Aug 17, 2005 at 08:53:28AM -0700, Darcy Buskermolen wrote:
> I have a realworld test case of delete cascade (approx 90 cascaded tables,
> some more than 8 levels deep) failing on 8.0.3 (and 8.1) , this is one of a
> few issues that is preventing me from upgrading a couple of 7.4 boxen to
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 recoll
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
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
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
> > > pass
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
On Tuesday 16 August 2005 09:17, Stephan Szabo wrote:
> On Tue, 16 Aug 2005, Tom Lane wrote:
> > [ redirected to -hackers ]
> >
> > I wrote:
> > > This suggests that we need a way to prevent immediate execution of
> > > freshly queued triggers at the end of a command fired by an FK trigger.
> > > I
On Tue, 16 Aug 2005, Tom Lane wrote:
> [ redirected to -hackers ]
>
> I wrote:
> > This suggests that we need a way to prevent immediate execution of
> > freshly queued triggers at the end of a command fired by an FK trigger.
> > If we could move them to the end of the trigger queue that the FK
>
[ redirected to -hackers ]
I wrote:
> This suggests that we need a way to prevent immediate execution of
> freshly queued triggers at the end of a command fired by an FK trigger.
> If we could move them to the end of the trigger queue that the FK
> operation itself is in, things would work reasona
