Thread: Enhancement proposal - detect chain of triggers from inside the trigger

I was wondering, would be a nice addition the ability to read the chain
of triggers (may be another trigger variable like TG_OP, called
"TG_CHAIN" or something else that will be an array with the name of the
triggers called before current trigger).

Would help debug database triggers that have cascaded events.

Regards,

Edson

On 01/15/2013 03:30 PM, Edson Richter wrote:
> I was wondering, would be a nice addition the ability to read the chain
> of triggers (may be another trigger variable like TG_OP, called
> "TG_CHAIN" or something else that will be an array with the name of the
> triggers called before current trigger).

Well for a given table triggers run in alphabetical name order if that
helps.

>
> Would help debug database triggers that have cascaded events.
>
> Regards,
>
> Edson
>
>


--
Adrian Klaver
adrian.klaver@gmail.com

Em 15/01/2013 21:36, Adrian Klaver escreveu:
> On 01/15/2013 03:30 PM, Edson Richter wrote:
>> I was wondering, would be a nice addition the ability to read the chain
>> of triggers (may be another trigger variable like TG_OP, called
>> "TG_CHAIN" or something else that will be an array with the name of the
>> triggers called before current trigger).
>
> Well for a given table triggers run in alphabetical name order if that
> helps.

The idea is to be to detect the chain of events among different tables.

A similar effect (for debugging purposes) can be achieved altering every
trigger function adding a "RAISE NOTICE 'you are on Trigger n'" at very
beginning, and read the messages after... until it explodes stack space.
But having the chain of calls, you could do something like

IF TG_CHAIN[0] = 'trigger_i_want_detect' THEN
   RAISE EXCEPTION 'database called this trigger twice. Check the chain
of events: %', TG_CHAIN;
END IF;


(I know this is only desirable at development and test time, never at
production).

Regards,

Edson

>
>>
>> Would help debug database triggers that have cascaded events.
>>
>> Regards,
>>
>> Edson
>>
>>
>
>

2013/1/16 Edson Richter <edsonrichter@hotmail.com>:
> I was wondering, would be a nice addition the ability to read the chain of
> triggers (may be another trigger variable like TG_OP, called "TG_CHAIN" or
> something else that will be an array with the name of the triggers called
> before current trigger).

-1

building dynamic used array, that should or should not used can
significantly decrease performance :(

if you need it, you can use workaround - session variables.

Regards

Pavel Stehule

>
> Would help debug database triggers that have cascaded events.
>
> Regards,
>
> Edson
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general

Pavel Stehule <pavel.stehule@gmail.com> writes:
> 2013/1/16 Edson Richter <edsonrichter@hotmail.com>:
>> I was wondering, would be a nice addition the ability to read the chain of
>> triggers (may be another trigger variable like TG_OP, called "TG_CHAIN" or
>> something else that will be an array with the name of the triggers called
>> before current trigger).

> -1

> building dynamic used array, that should or should not used can
> significantly decrease performance :(

I agree it wouldn't do to add cycles to every trigger for a feature that
only a small minority of them would use.  However, maybe we could expose
something like this as a function you'd call to get the information if
you want it, with nil-or-close-to-nil overhead if you don't.

In the long run, maybe some of the lesser-used existing trigger
variables should be converted to that style too ...

            regards, tom lane

Em 16/01/2013 14:18, Tom Lane escreveu:
> Pavel Stehule <pavel.stehule@gmail.com> writes:
>> 2013/1/16 Edson Richter <edsonrichter@hotmail.com>:
>>> I was wondering, would be a nice addition the ability to read the chain of
>>> triggers (may be another trigger variable like TG_OP, called "TG_CHAIN" or
>>> something else that will be an array with the name of the triggers called
>>> before current trigger).
>> -1
>> building dynamic used array, that should or should not used can
>> significantly decrease performance :(
> I agree it wouldn't do to add cycles to every trigger for a feature that
> only a small minority of them would use.  However, maybe we could expose
> something like this as a function you'd call to get the information if
> you want it, with nil-or-close-to-nil overhead if you don't.
>
> In the long run, maybe some of the lesser-used existing trigger
> variables should be converted to that style too ...
>
>             regards, tom lane
>
>
Sounds perfect for me! My concern was to have additional information
during debug only, with less performance penalty as possible in production.
There is one workaround (using RAISE NOTICE), but just because I felt
the pain on my skin, I did proposed the feature.

Regards,

Edson