On Tue, 2007-04-17 at 17:16 -0400, Tom Lane wrote:
> A recent discussion led me to the idea that FK triggers are fired
> unnecessarily during an UPDATE if the foreign-key column(s) contain
> any NULLs, because ri_KeysEqual() treats two nulls as unequal,
> and therefore we conclude the row has changed when it has not.
FK trigger *can be optimised away* is true. No need to have a discussion
about whether NULL == NULL, but the critical test is: if I overwrote it,
would you be able to tell? The answer is No, so away it goes.
> I claim that both ri_KeysEqual() and ri_OneKeyEqual() could consider
> two nulls to be equal. Furthermore it seems like ri_AllKeysUnequal()
> should do so too; the case can't arise at the moment because the sole
> caller already knows that one of the key sets contains no nulls, but
> if this weren't so, the optimization would be actively wrong if we
> concluded that two nulls were unequal.
>
> Comments?
>
> Also, I am wondering to what extent the ri_KeysEqual() calls in
> ri_triggers.c are redundant, given that commands/trigger.c now has
> the smarts to not even queue the trigger when those cases apply.
Would be good to document that behaviour in ri_triggers.c - I was
completely misled when I looked at the code a while back. Probably more
than one thing can go.
-- Simon Riggs EnterpriseDB http://www.enterprisedb.com