> -----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.
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 '
raise notice ''seeme'';
joel(at)joel=# select false and seeme();
joel(at)joel=# select true and seeme();
It certainly appears to be short circuiting for "select false and seeme()",
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() ?
Joel BURTON | joel(at)joelburton(dot)com | joelburton.com | aim: wjoelburton
Knowledge Management & Technology Consultant
In response to
pgsql-hackers by date
|Next:||From: Thomas Lockhart||Date: 2002-05-28 22:12:29|
|Subject: Re: Interval oddities|
|Previous:||From: Hannu Krosing||Date: 2002-05-28 19:48:07|
|Subject: Re: wierd AND condition evaluation for plpgsql|