Fix WHERE CURRENT OF when the referenced cursor uses an index-only scan. "UPDATE/DELETE WHERE CURRENT OF cursor_name" failed, with an error message like "cannot extract system attribute from virtual tuple", if the cursor was using a index-only scan for the target table. Fix it by digging the current TID out of the indexscan state.
It seems likely that the same failure could occur for CustomScan plans and perhaps some FDW plan types, so that leaving this to be treated as an internal error with an obscure message isn't as good an idea as it first seemed. Hence, add a bit of heaptuple.c infrastructure to let us deliver a more on-topic message. I chose to make the message match what you get for the case where execCurrentOf can't identify the target scan node at all, "cursor "foo" is not a simply updatable scan of table "bar"". Perhaps it should be different, but we can always adjust that later. In the future, it might be nice to provide hooks that would let custom scan providers and/or FDWs deal with this in other ways; but that's not a suitable topic for a back-patchable bug fix. It's been like this all along, so back-patch to all supported branches. Yugo Nagata and Tom Lane Discussion: https://postgr.es/m/20180201013349.937dfc5f.nag...@sraoss.co.jp Branch ------ REL9_4_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/0a0721f84c40ef3a511cd1b233579777b71d8bce Modified Files -------------- src/backend/access/common/heaptuple.c | 26 ++++++++++++ src/backend/executor/execCurrent.c | 79 ++++++++++++++++++++++++++--------- src/include/executor/tuptable.h | 2 + src/test/regress/expected/portals.out | 24 +++++++++++ src/test/regress/sql/portals.sql | 10 +++++ 5 files changed, 121 insertions(+), 20 deletions(-)
