Re: avoid pulling up subquerys that contain volatile functions? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: avoid pulling up subquerys that contain volatile functions?
Date
Msg-id 6755.1128875069@sss.pgh.pa.us
Whole thread Raw
In response to Re: avoid pulling up subquerys that contain volatile functions?  (Jaime Casanova <systemguards@gmail.com>)
Responses Re: avoid pulling up subquerys that contain volatile functions?
List pgsql-hackers
Jaime Casanova <systemguards@gmail.com> writes:
> On 10/8/05, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> This is exactly the same example discussed in previous threads on this
>> issue.  Do you think it will change anyone's mind?

> in any case, i still think that is better to get bad performance
> because i forgot to correctly mark a function that to get incorrect
> data from a correct query because a "gotcha"... there is a precedent
> for this in postgres???

Just to be clear, I'm in favor of changing it; but the majority opinion
in the previous discussion seemed to be against.

> ... but i don't understand why when i add the function
> contain_volatile_functions in the is_simple_subquery function i got
> the same results... :)

You should only be enforcing the restriction against the subquery's
target list anyway.  The expression_returns_set test is the model to
follow.  BTW, you'll also need to make some fixes in allpaths.c, else
you'll still get bit by qual pushdown; again, look for
expression_returns_set.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Volkan YAZICI
Date:
Subject: How TODO prevent PQfnumber() from lowercasing?
Next
From: "Neil Conway"
Date:
Subject: Re: fixing LISTEN/NOTIFY