Re: plpgsql and logical expression evaluation

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: wstrzalka <wstrzalka(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: plpgsql and logical expression evaluation
Date: 2008-04-23 14:32:20
Message-ID: 10385.1208961140@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Alvaro Herrera <alvherre(at)commandprompt(dot)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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tim Tassonis 2008-04-23 14:35:04 Re: initdb in 8.3
Previous Message mateo21 2008-04-23 14:29:46 Re: Bitmap Heap Scan takes a lot of time