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

>>>>> "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)