Fix executor/README to reflect disallowing SRFs in UPDATE.

The parenthetical comment here is obsoleted by commit a4c35ea1c.
Noted by Andres Freund.
This commit is contained in:
Tom Lane 2016-09-13 14:25:35 -04:00
parent a4c35ea1c2
commit fdc79e1909

View File

@ -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, 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 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 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 query returning the same set of scan tuples multiple times. Likewise,
is no explicit prohibition on SRFs in UPDATE, but the net effect will be SRFs are disallowed in an UPDATE's targetlist. There, they would have the
that only the first result row of an SRF counts, because all subsequent effect of the same row being updated multiple times, which is not very
rows will result in attempts to re-update an already updated target row. useful --- and updates after the first would have no effect anyway.
This is historical behavior and seems not worth changing.)