From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>, Laurent Wandrebeck <l(dot)wandrebeck(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Column level triggers |
Date: | 2008-10-15 16:17:35 |
Message-ID: | 22798.1224087455@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Scott Marlowe wrote:
>> Since you can check which columns have changed, it's pretty easy to
>> write a trigger that just skips its logic when none of the trigger
>> columns have changed.
> I think column-level triggers actually fire when one of the columns is
> written to, not only when the value there is distinct from the previous
> one. This small difference is not easy to emulate by comparing OLD and
> NEW in the trigger body.
So what happens when one of the target columns is modified by another
trigger, rather than by the SQL query? (For extra credit, what if it's
a trigger that comes after the column trigger in the firing order?)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | carlos.ohiggins | 2008-10-15 16:40:58 | create parent after children |
Previous Message | Richard Broersma | 2008-10-15 16:17:27 | Re: NATURAL JOINs |
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2008-10-15 16:23:18 | Re: autovacuum and reloptions |
Previous Message | Joshua Tolley | 2008-10-15 16:13:34 | Re: Cross-column statistics revisited |