From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Kyrill Alyoshin <kyrill(at)technolog(dot)ca> |
Cc: | pgsql-general(at)postgresql(dot)org, Gill Hauer <gilh(at)technolog(dot)ca> |
Subject: | Re: After Insert or Update Trigger Issues! |
Date: | 2005-03-28 02:01:52 |
Message-ID: | 4356.1111975312@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Kyrill Alyoshin <kyrill(at)technolog(dot)ca> writes:
> 1. MY FUNCTIONS
> CREATE OR REPLACE FUNCTION insert_stamp() RETURNS TRIGGER AS
> $audit_insert$
> BEGIN
> NEW.created_ts := 'now';
> NEW.updated_ts := 'now';
> RETURN NEW;
> END;
> $audit_insert$ LANGUAGE plpgsql;
Do you understand the difference between a BEFORE trigger and an AFTER
trigger? An AFTER trigger fires *after* the operation is done.
Therefore it can't affect the data that was stored. It's no surprise
that the above is a no-op when used as an AFTER trigger; it's just
modifying a row in memory that will be thrown away afterwards.
Usually AFTER triggers are used to propagate data to other tables;
in that scenario, what you want is precisely to know what the final
state of the row is, after all the BEFORE triggers got done doing their
things.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Fuhr | 2005-03-28 02:06:58 | Re: After Insert or Update Trigger Issues! |
Previous Message | Tom Lane | 2005-03-28 01:56:34 | Re: plpgsql no longer exists |