Postgres Pro
Downloads
Home   >   mailing lists

Re: BUG #15336: Wrong cursor's bacward fetch results in select with ALL(subquery) - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #15336: Wrong cursor's bacward fetch results in select with ALL(subquery)
Date
Msg-id 14723.1534514356@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #15336: Wrong cursor's bacward fetch results in select with ALL(subquery)  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Responses Re: BUG #15336: Wrong cursor's bacward fetch results in select with ALL(subquery)  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
List pgsql-bugs
Tree view 
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 by date:

Previous
From: Mark Lai
Date:
Subject: Re: BUG #15333: pg_dump error on large table -- "pg_dump: could notstat file...iso-8859-1 error"
Next
From: Alvaro Herrera
Date:
Subject: Re: BUG #15336: Wrong cursor's bacward fetch results in select withALL(subquery)