Обсуждение: 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