Skip site navigation (1) Skip section navigation (2)

Re: wierd AND condition evaluation for plpgsql

From: "Joel Burton" <joel(at)joelburton(dot)com>
To: "Peter Eisentraut" <peter_e(at)gmx(dot)net>,"Louis-David Mitterrand" <vindex(at)apartia(dot)org>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: wierd AND condition evaluation for plpgsql
Date: 2002-05-28 21:36:19
Message-ID: JGEPJNMCKODMDHGOBKDNMELOCPAA.joel@joelburton.com (view raw or flat)
Thread:
Lists: pgsql-hackers
> -----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


In response to

Responses

pgsql-hackers by date

Next:From: Thomas LockhartDate: 2002-05-28 22:12:29
Subject: Re: Interval oddities
Previous:From: Hannu KrosingDate: 2002-05-28 19:48:07
Subject: Re: wierd AND condition evaluation for plpgsql

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group