| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> |
| Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org, v(dot)g(dot)baranoff(at)gmail(dot)com |
| Subject: | Re: BUG #15336: Wrong cursor's bacward fetch results in select with ALL(subquery) |
| Date: | 2018-08-17 13:59:16 |
| Message-ID: | 14723.1534514356@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> writes:
> "Andrew" == Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2018-08-17 14:04:11 | Re: BUG #15336: Wrong cursor's bacward fetch results in select with ALL(subquery) |
| Previous Message | Mark Lai | 2018-08-17 13:56:56 | Re: BUG #15333: pg_dump error on large table -- "pg_dump: could not stat file...Unknown error" |