Boolean error

Lists: pgsql-general
From: Fabien Fournier <fabien(at)cyriacrea(dot)net>
To: pgsql-general(at)postgresql(dot)org
Subject: Boolean error
Date: 2004-11-27 15:41:09
Message-ID: 1101570070.20764.7.camel@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-general

Hello,

We are experiencing a strange error with the following request :

select cmp
from (select random () < 0.5 as cmp from pg_type) as tmp
where cmp;

With this request even false results are shown. This behaviour doesn't
appear when we don't join the boolean expression to a table to have
multiple lines. It is also seems to be independent of the selected
table.

Could you enlighten us about what is happening ?

Thanks !
--
Fabien Fournier


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Fabien Fournier <fabien(at)cyriacrea(dot)net>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Boolean error
Date: 2004-11-27 18:27:43
Message-ID: 27109.1101580063@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-general

Fabien Fournier <fabien(at)cyriacrea(dot)net> writes:
> We are experiencing a strange error with the following request :

> select cmp
> from (select random () < 0.5 as cmp from pg_type) as tmp
> where cmp;

> With this request even false results are shown.

I think the planner will flatten this into

select random() < 0.5 as cmp from pg_type where random() < 0.5;

and of course the two random() calls will usually produce different
results.

There was some talk awhile ago of preventing flattening when the
subquery targetlist contains volatile functions, but we didn't
have any consensus that the cure would be better than the disease.
(In particular, since user-defined functions default to being
considered volatile, such a restriction could easily cripple
optimization of subqueries.)

regards, tom lane


From: Greg Stark <gsstark(at)mit(dot)edu>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: Boolean error
Date: 2004-11-29 06:18:05
Message-ID: 874qj9uqjm.fsf@stark.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-general

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> There was some talk awhile ago of preventing flattening when the
> subquery targetlist contains volatile functions, but we didn't
> have any consensus that the cure would be better than the disease.
> (In particular, since user-defined functions default to being
> considered volatile, such a restriction could easily cripple
> optimization of subqueries.)

Thinking aloud... Postgres could have a VOLATILE function attribute to
explicitly mark functions requiring special care.

The default could be sort of a best-guess
usually-volatile-but-sometimes-takes-liberties-when-convenient compromise.
Perhaps eventually warning on functions created without being explicitly
VOLATILE/STABLE/IMMUTABLE.

Well, I guess Postgres can't warn on a valid SQL function if it's interested
in spec conformance. But it could be an option to do so.

--
greg