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

From: Edson Richter <edsonrichter(at)hotmail(dot)com>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: Enhancement proposal - detect chain of triggers from inside the trigger
Date: 2013-01-16 16:33:32
Message-ID: BLU0-SMTP61DBFBD4111944997E042ECF2C0@phx.gbl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Em 16/01/2013 14:18, Tom Lane escreveu:
> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
>> 2013/1/16 Edson Richter <edsonrichter(at)hotmail(dot)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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Adrian Klaver 2013-01-16 16:45:16 Re: plpython intermittent ImportErrors RESOLVED
Previous Message Brian Sutherland 2013-01-16 16:20:35 Re: plpython intermittent ImportErrors RESOLVED