From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Gierth <andrew@tao11.riddles.org.uk>
Cc: pgsql-bugs@lists.postgresql.org
Cc: v.g.baranoff@gmail.com
Subject: Re: BUG #15336: Wrong cursor's bacward fetch results in select with ALL(subquery)
Date: Fri, 17 Aug 2018 09:59:16 -0400
Message-ID: <14723.1534514356@sss.pgh.pa.us> (raw)
In-Reply-To: <87in492jrn.fsf@news-spur.riddles.org.uk>
References: <153449812167.1304.1741624125628126322@wrigleys.postgresql.org>
<87va892tf5.fsf@news-spur.riddles.org.uk>
<87mutl2pv1.fsf@news-spur.riddles.org.uk>
<87in492jrn.fsf@news-spur.riddles.org.uk>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, andrew@tao11.riddles.org.uk, pgsql-bugs@lists.postgresql.org, v.g.baranoff@gmail.com
Subject: Re: BUG #15336: Wrong cursor's bacward fetch results in select with ALL(subquery)
In-Reply-To: <14723.1534514356@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox