On Wed, 2002-05-29 at 02:36, Joel Burton wrote:
> > -----Original Message-----
> joel(at)joel=# select true and seeme();
> NOTICE: seeme
> (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
In response to
pgsql-hackers by date
|Next:||From: Joel Burton||Date: 2002-05-28 21:36:19|
|Subject: Re: wierd AND condition evaluation for plpgsql|
|Previous:||From: Tom Lane||Date: 2002-05-28 19:24:32|
|Subject: Re: Null values in indexes |