Stephan Szabo <sszabo@megazone.bigpanda.com> writes:
> On Fri, 16 Oct 2009, Tom Lane wrote:
>> I note BTW that we have some ad-hoc logic already that arranges to
>> suppress queuing of AFTER events for FK triggers, if the FK column
>> value has not changed. It might be interesting to look at whether
>> that hack could be unified with the user-accessible feature. It's
>> essentially a WHEN OLD.x IS NOT DISTINCT FROM NEW.x test.
> Note that one of those cases (RI_TRIGGER_FK) is a bit special due to the
> transaction id test. It might be worth seeing if a better solution is
> possible to cover the case in the comment if the above becomes possible,
> though.
The existing FK short-circuit code is presumably faster than generic
WHEN expression evaluation would be, so I wasn't really imagining that
we would take it out in favor of using the generic feature. But
possibly we could clean things up to some extent by treating the FK case
as a variant of generic WHEN. One particular thing I never much liked
about that hack is its dependence on specific function OIDs. I could
see replacing that with some representation that says "this trigger
has a special FK WHEN clause" as opposed to providing an expression
tree.
regards, tom lane
