Re: Can't ri_KeysEqual() consider two nulls as equal?
От | Simon Riggs |
---|---|
Тема | Re: Can't ri_KeysEqual() consider two nulls as equal? |
Дата | |
Msg-id | 1176845071.3635.548.camel@silverbirch.site обсуждение исходный текст |
Ответ на | Can't ri_KeysEqual() consider two nulls as equal? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Can't ri_KeysEqual() consider two nulls as equal?
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: