I wrote: > Now that I look at this, I strongly wonder whether whoever added > MergeAppend support here understood what they were doing. That > looks broken, because child nodes will typically be positioned on > tuples, whether or not the current top-level output came from them. > So I fear we could get a false-positive confirmation that some > tuple matches WHERE CURRENT OF.
Urgh, indeed it's buggy. With the attached test script I get ... BEGIN DECLARE CURSOR f1 | f2 ----+----- 1 | one (1 row) UPDATE 1 UPDATE 1 UPDATE 1 COMMIT f1 | f2 ----+------------- 1 | one updated (1 row) f1 | f2 ----+------------- 2 | two updated (1 row) f1 | f2 ----+--------------- 3 | three updated (1 row) where clearly only the row with f1=1 should have updated (and if you leave off ORDER BY, so as to get a Merge not MergeAppend plan, indeed only that row updates). I shall go fix this, and try to improve the evidently-inadequate comments in search_plan_tree. regards, tom lane
drop table if exists t1,t2,t3; create table t1 (f1 int unique, f2 text); insert into t1 values (1, 'one'); create table t2 (f1 int unique, f2 text); insert into t2 values (2, 'two'); create table t3 (f1 int unique, f2 text); insert into t3 values (3, 'three'); explain select * from t1 union all select * from t2 union all select * from t3 order by 1; begin; declare c cursor for select * from t1 union all select * from t2 union all select * from t3 order by 1; fetch 1 from c; update t1 set f2 = f2 || ' updated' where current of c; update t2 set f2 = f2 || ' updated' where current of c; update t3 set f2 = f2 || ' updated' where current of c; commit; table t1; table t2; table t3;