Re: wierd AND condition evaluation for plpgsql - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: wierd AND condition evaluation for plpgsql
Date
Msg-id 1022615288.1901.18.camel@rh72.home.ee
Whole thread Raw
In response to Re: wierd AND condition evaluation for plpgsql  ("Joel Burton" <joel@joelburton.com>)
Responses Re: wierd AND condition evaluation for plpgsql  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, 2002-05-29 at 02:36, Joel Burton wrote:
> > -----Original Message-----
> 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() ?

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) ?

------------------------
Hannu




pgsql-hackers by date:

Previous
From: "Joel Burton"
Date:
Subject: Re: wierd AND condition evaluation for plpgsql
Next
From: Thomas Lockhart
Date:
Subject: Re: Interval oddities