Remove faulty support for MergeAppend plan with WHERE CURRENT OF.
authorTom Lane <tgl@sss.pgh.pa.us>
Tue, 19 Jan 2021 18:25:33 +0000 (13:25 -0500)
committerTom Lane <tgl@sss.pgh.pa.us>
Tue, 19 Jan 2021 18:26:01 +0000 (13:26 -0500)
commitfe8edbb8267adf24ba3b392ac6229b96c4287f93
treee7fa140162c034e5efd3b43e6dd26c27739e3c4a
parentffbf1746354a44a16d4d525d62226aa65fdb4e69
Remove faulty support for MergeAppend plan with WHERE CURRENT OF.

Somebody extended search_plan_tree() to treat MergeAppend exactly
like Append, which is 100% wrong, because unlike Append we can't
assume that only one input node is actively returning tuples.
Hence a cursor using a MergeAppend across a UNION ALL or inheritance
tree could falsely match a WHERE CURRENT OF query at a row that
isn't actually the cursor's current output row, but coincidentally
has the same TID (in a different table) as the current output row.

Delete the faulty code; this means that such a case will now return
an error like 'cursor "foo" is not a simply updatable scan of table
"bar"', instead of silently misbehaving.  Users should not find that
surprising though, as the same cursor query could have failed that way
already depending on the chosen plan.  (It would fail like that if the
sort were done with an explicit Sort node instead of MergeAppend.)

Expand the clearly-inadequate commentary to be more explicit about
what this code is doing, in hopes of forestalling future mistakes.

It's been like this for awhile, so back-patch to all supported
branches.

Discussion: https://postgr.es/m/482865.1611075182@sss.pgh.pa.us
src/backend/executor/execCurrent.c