Re: pg_trigger_depth() v3 (was: TG_DEPTH)

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: <fgp(at)phlo(dot)org>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_trigger_depth() v3 (was: TG_DEPTH)
Date: 2012-01-15 20:05:42
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

"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.


Attachment Content-Type Size
tg_depth.v3.patch application/octet-stream 10.0 KB


Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2012-01-15 20:23:07 Re: Our poll() based WaitLatch implementation is broken
Previous Message Gabriele Bartolini 2012-01-15 20:02:56 Re: Dry-run mode for pg_archivecleanup