Re: Making AFTER triggers act properly in PL functions - Mailing list pgsql-hackers

From Stephan Szabo
Subject Re: Making AFTER triggers act properly in PL functions
Date
Msg-id 20040908134705.K54420@megazone.bigpanda.com
Whole thread Raw
In response to Re: Making AFTER triggers act properly in PL functions  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Making AFTER triggers act properly in PL functions  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Making AFTER triggers act properly in PL functions  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, 8 Sep 2004, Tom Lane wrote:

> Hmm.  Here's a slightly off the wall idea: following SET CONSTRAINTS,
> scan the pending-triggers list twice.  The first time, you determine
> which triggers you need to fire, and mark them "in progress" by your
> transaction.  The second time through, you actually fire the ones you
> marked, and change their marking to "done".  The "in progress" ones
> wouldn't be touched by the hypothetical inner SET CONSTRAINTS.
>
> It wouldn't quite work to use just transaction ID as the marker, since
> the inner SET CONSTRAINTS is very possibly done without using a
> subtransaction.  But command ID or query nesting level or some such
> would work.  I think the main concern here would be the space cost of
> adding still another field to the trigger records ... is it worth it?

Would it be possible to basically alias the space for dte_done_xid to hold
either the xid if it's done or the <whatever> if it's in progress? That's
ugly, but it would presumably not increase the size of the record.


pgsql-hackers by date:

Previous
From: David Fetter
Date:
Subject: Re: Geometry regression test failure, CVS HEAD, Mac OS/X
Next
From: Andrew Dunstan
Date:
Subject: Re: Geometry regression test failure, CVS HEAD, Mac OS/X