On 23 Kwi, 16:32, [EMAIL PROTECTED] (Tom Lane) wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED])
> 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
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
