From: | "Simon Riggs" <simon(at)2ndquadrant(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Stephan Szabo" <sszabo(at)megazone(dot)bigpanda(dot)com>, <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: Can't ri_KeysEqual() consider two nulls as equal? |
Date: | 2007-04-17 21:24:30 |
Message-ID: | 1176845071.3635.548.camel@silverbirch.site |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Jim C. Nasby | 2007-04-17 21:28:58 | Re: where to write small reusable functions ? |
Previous Message | Bruce Momjian | 2007-04-17 21:22:51 | pgsql: Also done for PL/pgSQL: < o Add support for WITH HOLD and |