tirny wrote:
I don't understand. Can you explain what the problem is?

-Neil


---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

On Wed, 04 May 2005 11:52:32 +1000, Neil Conway <neilc (AT) samurai (DOT) com> wrote:
I think they mean that it doesn't do short-circuit evaluation.

[to tirny]
If so, see explanation in the documentation at the bottom of
http://www.postgresql.org/docs/8.0/s...pressions.html

klint.

+---------------------------------------+-----------------+
: Klint Gore : "Non rhyming :
: EMail : kg (AT) kgb (DOT) une.edu.au : slang - the :
: Snail : A.B.R.I. : possibilities :
: Mail University of New England : are useless" :
: Armidale NSW 2351 Australia : L.J.J. :
: Fax : +61 2 6772 5376 : :
+---------------------------------------+-----------------+

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo (AT) postgresql (DOT) org

Klint Gore <kg (AT) kgb (DOT) une.edu.au> writes:
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 majordomo (AT) postgresql (DOT) org