From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | Edson Richter <edsonrichter(at)hotmail(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Enhancement proposal - detect chain of triggers from inside the trigger |
Date: | 2013-01-16 16:18:48 |
Message-ID: | 26296.1358353128@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Rob Sargent | 2013-01-16 16:20:07 | Re: SELECT * and column ordering |
Previous Message | Edson Richter | 2013-01-16 15:56:01 | Triggers operations and log_statement = all not working? |