Update obsolete comments.
authorRobert Haas <rhaas@postgresql.org>
Mon, 26 Sep 2011 17:12:22 +0000 (13:12 -0400)
committerRobert Haas <rhaas@postgresql.org>
Mon, 26 Sep 2011 17:12:22 +0000 (13:12 -0400)
This was partially fixed by 57fdb2b0d835fe201434fc28bf5dabf83ada26d1,
back in 2005, but it missed a couple of spots.

YAMAMOTO Takashi

src/backend/executor/execProcnode.c

index 8bdfad2222380c9b7c4e88919267116f231d1d20..284fc6a63b7e88fdfa16b33405d56e6331488e1a 100644 (file)
@@ -55,7 +55,7 @@
  *     of ExecInitNode() is a plan state tree built with the same structure
  *     as the underlying plan tree.
  *
- *   * Then when ExecRun() is called, it calls ExecutePlan() which calls
+ *   * Then when ExecutorRun() is called, it calls ExecutePlan() which calls
  *     ExecProcNode() repeatedly on the top node of the plan state tree.
  *     Each time this happens, ExecProcNode() will end up calling
  *     ExecNestLoop(), which calls ExecProcNode() on its subplans.
@@ -65,7 +65,7 @@
  *     form the tuples it returns.
  *
  *   * Eventually ExecSeqScan() stops returning tuples and the nest
- *     loop join ends.  Lastly, ExecEnd() calls ExecEndNode() which
+ *     loop join ends.  Lastly, ExecutorEnd() calls ExecEndNode() which
  *     calls ExecEndNestLoop() which in turn calls ExecEndNode() on
  *     its subplans which result in ExecEndSeqScan().
  *