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

Re: wierd AND condition evaluation for plpgsql

From: Hannu Krosing <hannu(at)tm(dot)ee>
To: Joel Burton <joel(at)joelburton(dot)com>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>,Louis-David Mitterrand <vindex(at)apartia(dot)org>,pgsql-hackers(at)postgresql(dot)org
Subject: Re: wierd AND condition evaluation for plpgsql
Date: 2002-05-28 19:48:07
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Wed, 2002-05-29 at 02:36, Joel Burton wrote:
> > -----Original Message-----
> 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() ?

Are these intricacies of SQL standardised anywhere ?

I know that gcc and other ccs can achieve different results depending on
optimisation level - usually this is considered a bug.

But as PG runs always (?) at the maximum optimisation, should there be
such guarantees ?

Or is it something that should be ind doc's/faq's (- don't rely on side
effects) ?


In response to


pgsql-hackers by date

Next:From: Joel BurtonDate: 2002-05-28 21:36:19
Subject: Re: wierd AND condition evaluation for plpgsql
Previous:From: Tom LaneDate: 2002-05-28 19:24:32
Subject: Re: Null values in indexes

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