| 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: | Whole Thread | Raw Message | 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 |