Re: plpgsql and logical expression evaluation - Mailing list pgsql-general

From Tom Lane
Subject Re: plpgsql and logical expression evaluation
Date
Msg-id 10385.1208961140@sss.pgh.pa.us
Whole thread Raw
In response to Re: plpgsql and logical expression evaluation  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-general
Alvaro Herrera <alvherre@commandprompt.com> 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

pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: Qty of WAL files
Next
From: Tim Tassonis
Date:
Subject: Re: initdb in 8.3