Klint Gore <[EMAIL PROTECTED]> writes:
> On Wed, 04 May 2005 11:52:32 +1000, Neil Conway <[EMAIL PROTECTED]> wrote:
>> I don't understand. Can you explain what the problem is?
> I think they mean that it doesn't do short-circuit evaluation.
AFAICS the claimed example cannot exhibit any different behavior whether
it's short-circuit or not. I have seen some related issues though, like
IF tg_op = 'UPDATE' AND NEW.foo = 42 THEN ...
In a trigger that is also used for DELETE operations this will fail
--- not because the AND itself isn't short-circuit, but because plpgsql
has to pass down the parameters for the whole IF-expression before the
AND gets to run at all, and so it's forced to evaluate NEW.* which
fails in a DELETE trigger.
We could fix some variants of this problem by modifying plpgsql to
handle top-level AND and OR by itself (ie, split the above into two
separate SQL-expression evaluations with the AND being processed by
plpgsql itself). However the added overhead of multiple executor
calls would be large, and it still wouldn't fix every such case.
Given that we don't promise AND/OR to always behave in short-circuit
fashion anyway, my reaction to the bug report is basically "tough beans,
this is SQL not C" ...
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
