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;
