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

From Martijn van Oosterhout
Subject Re: plpgsql and logical expression evaluation
Date
Msg-id 20080423083954.GA16761@svana.org
Whole thread Raw
In response to plpgsql and logical expression evaluation  (wstrzalka <wstrzalka@gmail.com>)
Responses Re: plpgsql and logical expression evaluation  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-general
On Tue, Apr 22, 2008 at 02:41:50AM -0700, wstrzalka wrote:
> One of the annoying things in plpgsql is logical expression
> evaluation.
>
> In most (all??) languages I know, logical expression like:
>
>      if ( [A_true_expression] or [B_false_expression] ) then
>
> will stop evaluating when the A expression will be evaluated as a
> TRUE.

I guess you should complain to the SQL design comittee, SQL is a
declarative language not a procedural language and the order of the
expressions in AND/OR is not important to the evaluation.

> It don't work for insert as the part designed for UPDATE will be
> evaluated, while there is no OLD for an insert operation.
> So the code looks like that:
>
> IF (TG_OP = 'INSERT') THEN
>         -- DO SOMETHING
> ELSIF  (TG_OP = 'UPDATE' AND NEW.status <> OLD.status) THEN
>         -- DO THE SAME AS ABOVE
> END IF;

You could use a flag variable.

> Is there any reason for that like side effects (please give me any
> example?) or it's just not yet done optimization?

The spec explicitly says it doesn't matter and it removes the
possibility of optimisation (in many queries it is important that the
optimiser can execute conditions in any order it likes).

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> Please line up in a tree and maintain the heap invariant while
> boarding. Thank you for flying nlogn airlines.

Attachment

pgsql-general by date:

Previous
From: "A. Kretschmer"
Date:
Subject: Re: Updating with a subselect
Next
From: Martijn van Oosterhout
Date:
Subject: Re: Updating with a subselect