Re: pg_trigger_depth() v3 (was: TG_DEPTH)
Kevin Grittner <kevin.grittner@wicourts.gov>
From: "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
To: <fgp@phlo.org>
Cc: <pgsql-hackers@postgresql.org>
Date: 2012-01-15T20:05:42Z
Lists: pgsql-hackers
Attachments
- tg_depth.v3.patch (application/octet-stream) patch v3
"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