On Jan 30, 2007, at 1:17 PM, Simon Riggs wrote:
It would be even better if there was some way of not executing the
trigger at all if we knew that the UPDATE statement doesn't SET the FK
columns.
Other databases allow you to put a WHERE or CHECK clause on triggers,
so that they will only fire
On Tue, 2007-01-30 at 15:24 -0500, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > Any objections to implementing this?
>
> Only that it was done a long time ago --- see
> RI_FKey_keyequal_upd_pk/fk.
OK, funny guy. :-)
Its not very well documented, is all I can say. The code comm
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> Any objections to implementing this?
Only that it was done a long time ago --- see
RI_FKey_keyequal_upd_pk/fk.
> It would be even better if there was some way of not executing the
> trigger at all if we knew that the UPDATE statement doesn't SET the FK
My understanding is that an UPDATE statement will fire exactly the same
number of RI checks as does an INSERT, in all cases.
ISTM possible that we could optimise away some RI checks in the case of
UPDATEs. This might or might not save some cycles but it will definitely
reduce the amount of locking
