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: | 1022615288.1901.18.camel@rh72.home.ee |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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) ?
------------------------
Hannu
From | Date | Subject | |
---|---|---|---|
Next Message | Joel Burton | 2002-05-28 21:36:19 | Re: wierd AND condition evaluation for plpgsql |
Previous Message | Tom Lane | 2002-05-28 19:24:32 | Re: Null values in indexes |