From: Andrew Gierth <andrew@tao11.riddles.org.uk>
To: pgsql-bugs@lists.postgresql.org
To: 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 11:27:46 +0100
Message-ID: <87va892tf5.fsf@news-spur.riddles.org.uk> (raw)
In-Reply-To: <153449812167.1304.1741624125628126322@wrigleys.postgresql.org>
References: <153449812167.1304.1741624125628126322@wrigleys.postgresql.org>
>>>>> "PG" == PG Bug reporting form <noreply@postgresql.org> writes:
PG> fetch backward 9 from "mycursor";
PG> commit;
PG> The result set is wrong (9, 8, 7, 6, 5, 4, 3, 2, 1).
PG> It seems that selection predicate is ignored.
PG> This bug has been reproduced with PostgreSQL 9.6 and 10.0
I wonder if we have a contender here for the oldest reported bug in PG
history; while I haven't tested anything older than 9.5, the incorrect
logic seems to date back to the introduction of subqueries in
6.something.
Here is a simpler test case:
begin;
declare foo cursor for select * from generate_series(1,3) i where i <> all (values (2));
fetch all from foo; -- returns the expected 2 rows
fetch backward all from foo; -- assertion failure, or incorrect result
The problem is that the scan direction is being set to "backward" in the
EState, and as a result the subquery evaluation is run in the backward
direction too, which obviously doesn't do anything sensible. The
assertion failure is from the tuplestore code complaining about doing a
backward fetch on a tuplestore not initialized for backward access.
I'm really not sure yet what the correct fix is, though.
--
Andrew (irc:RhodiumToad)
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: 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: <87va892tf5.fsf@news-spur.riddles.org.uk>
* 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