Alvaro Herrera <alvherre@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
