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?  (Jaime Casanova <systemguards@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Volkan YAZICI
Дата:
Сообщение: How TODO prevent PQfnumber() from lowercasing?
Следующее
От: "Neil Conway"
Дата:
Сообщение: Re: fixing LISTEN/NOTIFY