On 23 Kwi, 16:32, t...@xxxxxxxxxxxxx (Tom Lane) wrote: > Alvaro Herrera <alvhe...@xxxxxxxxxxxxxxxxx> writes: > > I think this business of non-shortcircuiting boolean operators is just > > an artifact of the fact that PL/pgSQL hands off expression to the SQL > > engine for evaluation. > > The complainant is not actually complaining about non-shortcircuiting > boolean operators --- he thinks he is, but he's 100% mistaken. The > reason he's got a problem in the given example is that plpgsql has to > provide parameter values for every parameter in the whole expression > before it ships it off to the main engine. ExecEvalAnd actually *does* > know about short-circuiting, but it doesn't help because control never > gets that far. > > Even if we rejiggered things so that supplying parameter values could be > done lazily, there's the little problem that we can't even parse the > expression without knowing the types of the parameters. The correct > analogy for what the OP tried to do is writing in C > > if (x == 0 || no_such_var == 0) > > and expecting the "undefined variable no_such_var" failure not to be > reported if x is zero. Since it's happening at compile time, that's > not going to happen. > > regards, tom lane > > -- > Sent via pgsql-general mailing list (pgsql-gene...@xxxxxxxxxxxxxx) > To make changes to your subscription:http://www.postgresql.org/mailpref/pgsql-general Yes. You are right. I didn't realized what my complain was about. But the 'no_such_var' example is great and explains what I was trying to do, and why it doesn't work. So - does it mean that the whole IF-ELSE-ENDIF is not parsed at once - but lazy-parsed when the control reaches it, while the IF condition is parsed as a single expression and therefore I get error in this case? Thanks a lot. regards wojtek
