Re: BUG #15336: Wrong cursor's bacward fetch results in select with ALL(subquery)

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: BUG #15336: Wrong cursor's bacward fetch results in select with ALL(subquery)
Дата
Msg-id 14723.1534514356@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: BUG #15336: Wrong cursor's bacward fetch results in select with ALL(subquery)  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Ответы Re: BUG #15336: Wrong cursor's bacward fetch results in select with ALL(subquery)  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Список pgsql-bugs
Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
> "Andrew" == Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
>  Andrew> I'm guessing that locally saving/restoring the scan direction
>  Andrew> in ExecSubPlan is going to be the best option; it seems to fix
>  Andrew> the problem, I'll post a patch in a bit.

> It turns out to be also necessary to do this in ExecSetParamPlan, though
> I couldn't find a way to make a stable regression test for that - my
> manual tests were based on putting a subselect inside a volatile
> construct like CASE WHEN random() < x THEN.

Looks sane to me ... and a bit astonishing that we didn't run into
this a decade or two back.

            regards, tom lane


В списке pgsql-bugs по дате отправления:

Предыдущее
От: Mark Lai
Дата:
Сообщение: Re: BUG #15333: pg_dump error on large table -- "pg_dump: could notstat file...iso-8859-1 error"
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: BUG #15336: Wrong cursor's bacward fetch results in select withALL(subquery)