Re: search_plan_tree(): handling of non-leaf CustomScanState nodes causes segfault

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