Re: plpgsql and logical expression evaluation

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: plpgsql and logical expression evaluation
Дата
Msg-id 10385.1208961140@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: plpgsql and logical expression evaluation  (Alvaro Herrera <alvherre@commandprompt.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Qty of WAL files
Следующее
От: Tim Tassonis
Дата:
Сообщение: Re: initdb in 8.3