summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorTom Lane2016-09-13 18:25:35 +0000
committerTom Lane2016-09-13 18:25:35 +0000
commitfdc79e1909dc3866a385ffb74bdd6ce6a082a300 (patch)
tree0de16e5518e01230bed5dda4b7b8b071b263c2a5
parenta4c35ea1c2f05dd5b56739fcd0dc36a4870ea0c0 (diff)
Fix executor/README to reflect disallowing SRFs in UPDATE.
The parenthetical comment here is obsoleted by commit a4c35ea1c. Noted by Andres Freund.
-rw-r--r--src/backend/executor/README9
1 files changed, 4 insertions, 5 deletions
diff --git a/src/backend/executor/README b/src/backend/executor/README
index 8afa1e3e4a..f1d1e4c76c 100644
--- a/src/backend/executor/README
+++ b/src/backend/executor/README
@@ -195,8 +195,7 @@ the entire row value in the join output row.
We disallow set-returning functions in the targetlist of SELECT FOR UPDATE,
so as to ensure that at most one tuple can be returned for any particular
set of scan tuples. Otherwise we'd get duplicates due to the original
-query returning the same set of scan tuples multiple times. (Note: there
-is no explicit prohibition on SRFs in UPDATE, but the net effect will be
-that only the first result row of an SRF counts, because all subsequent
-rows will result in attempts to re-update an already updated target row.
-This is historical behavior and seems not worth changing.)
+query returning the same set of scan tuples multiple times. Likewise,
+SRFs are disallowed in an UPDATE's targetlist. There, they would have the
+effect of the same row being updated multiple times, which is not very
+useful --- and updates after the first would have no effect anyway.