Re: wierd AND condition evaluation for plpgsql

> -----Original Message-----
> From: pgsql-hackers-owner(at)postgresql(dot)org
> [mailto:pgsql-hackers-owner(at)postgresql(dot)org]On Behalf Of Peter Eisentraut
> Sent: Tuesday, May 28, 2002 12:53 PM
> To: Louis-David Mitterrand
> Cc: pgsql-hackers(at)postgresql(dot)org
> Subject: Re: [HACKERS] wierd AND condition evaluation for plpgsql
>
>
> Louis-David Mitterrand writes:
>
> > Shouldn't plpgsql shortcut AND conditions when a previous one fails, as
> > perl does?
>
> Shouldn't perl evaluate all operands unconditionally, like plpgsql does?
>
> Seriously, if you want to change this you have to complain to the SQL
> standards committee.

Peter --

But PG does short-circuit for evaluation, doesn't it? His question was
confusing evaluation versus syntax checking and statement preparation.

create function seeme() returns bool as '
begin
raise notice ''seeme'';
return true;
end'
language plpgsql;

joel(at)joel=# select false and seeme();
?column?
----------
f
(1 row)

joel(at)joel=# select true and seeme();
NOTICE: seeme
?column?
----------
t
(1 row)

It certainly appears to be short circuiting for "select false and seeme()",
for instance.

It appears that this isn't short-circuiting by order of expressions, however
(as Perl and other languages do); for example, "select seeme() or true"
doesn't ever get to seeme(). I assume PG can simply see that the statement
"true" will evaluate to true (clever, that PG!), and therefore it doesn't
have to evaluate seeme() ?

- J.

Joel BURTON | joel(at)joelburton(dot)com | joelburton.com | aim: wjoelburton
Knowledge Management & Technology Consultant