Thread

1. Re: pg_trigger_depth() v3 (was: TG_DEPTH)

   Kevin Grittner <kevin.grittner@wicourts.gov> — 2012-01-15T20:05:42Z

   "Kevin Grittner"  wrote:
   > Florian Pflug  wrote:
    
   >> The trigger depth is incremented before calling the trigger
   >> function in ExecCallTriggerFunc() and decremented right
   >> afterwards, which seems fine - apart from the fact that the
   >> decrement is skipped in case of an error. The patch handles that
   >> by saving respectively restoring the value of pg_depth in
   >> PushTransaction() respectively {Commit,Abort}SubTransaction().
   >>
   >> While I can't come up with a failure case for that approach, it
   >> seems rather fragile - who's to say that nested trigger
   >> invocations correspond that tightly to sub-transaction?
    
   >> I believe the same effect could be achieved more cleanly by
   >> a TRY/CATCH block in ExecCallTriggerFunc().
    
   Done that way in this version.
    
   >> * Other in-core PLs
   >> As it stands, the patch only export tg_depth to plpgsql functions,
   >> not to functions written in one of the other in-core PLs. It'd be
   >> good to change that, I believe - otherwise the other PLs become
   >> second-class citizens in the long run.
   > 
   > Are you suggesting that this be implemented as a special trigger
   > variable in every PL, or that it simply be a regular function that
   > returns zero when not in a trigger and some positive value when
   > called from a trigger? The latter seems like a pretty good idea to
   > me. If that is done, is there any point to *also* having a TG_DEPTH
   > trigger variable in plpgsql? (I don't think there is.)
    
   I dropped the TG_DEPTH name and the patch just supports a
   pg_trigger_depth() function now.  Useful values are probably:
    
   0: No trigger active on the connection.
   1: Top level trigger.  Useful to restrict certain DML to be allowed
      only from triggers.
   >1: OK to do trigger-restricted DML.
   greater than expected maximum depth: warn before hard crash
    
   >> [questions about code coverage in regression tests]
    
   I altered the tests to improve code coverage.  In addition, since
   this is no longer just a plpgsql feature, I move the tests to the
   triggers.sql file.
    
   -Kevin
   
   
   

2. Re: pg_trigger_depth() v3 (was: TG_DEPTH)

   Alvaro Herrera <alvherre@commandprompt.com> — 2012-01-25T16:25:46Z

   
   Committed, with OID change.  Thanks.
   
   I tested it with plphp just for the heck of it and it worked
   wonderfully.
   
   -- 
   Álvaro Herrera <alvherre@commandprompt.com>
   The PostgreSQL Company - Command Prompt, Inc.
   PostgreSQL Replication, Consulting, Custom Development, 24x7 support