Re: pg_trigger_depth() v3 (was: TG_DEPTH)

"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