Re: wierd AND condition evaluation for plpgsql

> -----Original Message-----
> From: pgsql-hackers-owner@postgresql.org
> [mailto:pgsql-hackers-owner@postgresql.org]On Behalf Of Peter Eisentraut
> Sent: Tuesday, May 28, 2002 12:53 PM
> To: Louis-David Mitterrand
> Cc: pgsql-hackers@postgresql.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@joel=# select false and seeme();?column?
----------f
(1 row)

joel@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@joelburton.com | joelburton.com | aim: wjoelburton
Knowledge Management & Technology Consultant