Thread: detect initiator of update/delete action
Dear list, I want to create a function on a table that does something before deletion on a table, e.g. like create or replace function table1_del() returns trigger as $$ begin update table1 set column1= substr(column2,1,10); insert into table1_hist values ( old.column1; return OLD; end; $$ language plpgsql volatile; create trigger table1_del before delete on table1 for each row execute procedure table1_del(); However, I need to separate this function with an if-statement depending on how the deletion was initiated. There are two cases: 1. if the deletion was executed through a user action, both the update and insert statement of the 'table1_del' function should be executed 2. if the deletion was initiated through a function fired from another table, only the insert statement should be executed Is there a way in postgres to detect if an action (here:deletion) was initiated by user interaction or a function? Any help greatly appreciated! Stefan -- View this message in context: http://postgresql.1045698.n5.nabble.com/detect-initiator-of-update-delete-action-tp5771708.html Sent from the PostgreSQL - sql mailing list archive at Nabble.com.
On Fri, Sep 20, 2013 at 9:52 AM, ssylla <stefansylla@gmx.de> wrote: > There are two cases: > 1. if the deletion was executed through a user action, both the update and > insert statement of the 'table1_del' function should be executed > 2. if the deletion was initiated through a function fired from another > table, only the insert statement should be executed There is nothing that allows a trigger to distinguish such kind of invocation. However there is a different kind of approach that comes into my mind and that I would try: within the trigger test for a specific temporary table and a value into it. In the case the trigger is invoked "directly" (1) the table will not be created, while in the case of a trigger chain the other trigger is responsible for populating the temp table (and the current trigger to truncate it). Of course a drawback of this approach is that you need to create and populate the temp table on each trigger of an higher level in the call chain. Luca