aboutsummaryrefslogtreecommitdiff
path: root/src/backend/executor/execMain.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2013-01-24 18:34:00 -0500
committerTom Lane <tgl@sss.pgh.pa.us>2013-01-24 18:34:00 -0500
commit2ddc600f8f0252a0864e85d5cc1eeb3b9687d7e9 (patch)
tree3df9d556becd674b06e19df2d3e3251c9a98fcf2 /src/backend/executor/execMain.c
parent1068771abfeec148a9c1ce4782785bddc1982070 (diff)
downloadpostgresql-2ddc600f8f0252a0864e85d5cc1eeb3b9687d7e9.tar.gz
postgresql-2ddc600f8f0252a0864e85d5cc1eeb3b9687d7e9.zip
Fix SPI documentation for new handling of ExecutorRun's count parameter.
Since 9.0, the count parameter has only limited the number of tuples actually returned by the executor. It doesn't affect the behavior of INSERT/UPDATE/DELETE unless RETURNING is specified, because without RETURNING, the ModifyTable plan node doesn't return control to execMain.c for each tuple. And we only check the limit at the top level. While this behavioral change was unintentional at the time, discussion of bug #6572 led us to the conclusion that we prefer the new behavior anyway, and so we should just adjust the docs to match rather than change the code. Accordingly, do that. Back-patch as far as 9.0 so that the docs match the code in each branch.
Diffstat (limited to 'src/backend/executor/execMain.c')
-rw-r--r--src/backend/executor/execMain.c6
1 files changed, 4 insertions, 2 deletions
diff --git a/src/backend/executor/execMain.c b/src/backend/executor/execMain.c
index 23a6a612565..e39911f16b2 100644
--- a/src/backend/executor/execMain.c
+++ b/src/backend/executor/execMain.c
@@ -228,7 +228,9 @@ standard_ExecutorStart(QueryDesc *queryDesc, int eflags)
* we retrieve up to 'count' tuples in the specified direction.
*
* Note: count = 0 is interpreted as no portal limit, i.e., run to
- * completion.
+ * completion. Also note that the count limit is only applied to
+ * retrieved tuples, not for instance to those inserted/updated/deleted
+ * by a ModifyTable plan node.
*
* There is no return value, but output tuples (if any) are sent to
* the destination receiver specified in the QueryDesc; and the number
@@ -1358,7 +1360,7 @@ ExecEndPlan(PlanState *planstate, EState *estate)
/* ----------------------------------------------------------------
* ExecutePlan
*
- * Processes the query plan until we have processed 'numberTuples' tuples,
+ * Processes the query plan until we have retrieved 'numberTuples' tuples,
* moving in the specified direction.
*
* Runs to completion if numberTuples is 0