Lists: | pgsql-hackers |
---|
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 |
Message-ID: | 4F12DD36020000250004480D@gw.wicourts.gov |
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.
-Kevin
Attachment | Content-Type | Size |
---|---|---|
tg_depth.v3.patch | application/octet-stream | 10.0 KB |
From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Kevin Grittner <kevin(dot)grittner(at)wicourts(dot)gov> |
Cc: | fgp <fgp(at)phlo(dot)org>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_trigger_depth() v3 (was: TG_DEPTH) |
Date: | 2012-01-25 16:25:46 |
Message-ID: | 1327508674-sup-3291@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
Committed, with OID change. Thanks.
I tested it with plphp just for the heck of it and it worked
wonderfully.
--
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support