From: | "Froggy / Froggy Corp(dot)" <froggy(at)froggycorp(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: [PL/PGSQL] (Bug/Feature problem) with recursive Trigger |
Date: | 2006-05-27 21:07:37 |
Message-ID: | 4478BF99.DCFF7CF3@froggycorp.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Its my plan in fact, it was to make some optimisation, because i need to
copy all the test from the BEFORE statement to the AFTER.
Thx for your help,
Regards,
Tom Lane wrote:
>
> "Froggy / Froggy Corp." <froggy(at)froggycorp(dot)com> writes:
> > Tom Lane wrote:
> >> This is a really badly designed trigger anyway: why don't you just
> >> modify the NEW row, instead of incurring orders of magnitude more work
> >> by launching an entire new SQL command?
>
> > I make some reorganization of my table when user make an update. The
> > trigger need to be able to support lot of case, so to make
> > reorganization more simple, i make some test, and change or make change
> > of this table by other part of trigger which are on after_update or
> > before_update.
>
> If you are cascading changes to other rows, you should do them in AFTER
> triggers. It's not really very sensible to try to do that in a BEFORE
> trigger, because a BEFORE trigger shouldn't assume it's seeing the final
> version of the row. BEFORE triggers are good for checking or adjusting
> the data in the proposed new row, but for pushing consequences out to
> other rows, use an AFTER trigger.
>
> regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Matthew Peter | 2006-05-27 21:25:02 | Re: Invoke diff from plpgsql? |
Previous Message | Tom Lane | 2006-05-27 20:59:37 | Re: [PL/PGSQL] (Bug/Feature problem) with recursive Trigger |