Re: avoid pulling up subquerys that contain volatile functions?
От | Tom Lane |
---|---|
Тема | Re: avoid pulling up subquerys that contain volatile functions? |
Дата | |
Msg-id | 6755.1128875069@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: avoid pulling up subquerys that contain volatile functions? (Jaime Casanova <systemguards@gmail.com>) |
Ответы |
Re: avoid pulling up subquerys that contain volatile functions?
|
Список | 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 по дате отправления: