"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