Improve C comment about why we return "0 0" for some tags.
authorBruce Momjian
Sat, 13 Feb 2010 22:45:41 +0000 (22:45 +0000)
committerBruce Momjian
Sat, 13 Feb 2010 22:45:41 +0000 (22:45 +0000)
src/backend/tcop/pquery.c

index 05068fa406c9176a00a5bd20de5054b12082b3e1..42960b82250a65b2ae112e89728e6ef461e8bdae 100644 (file)
@@ -8,7 +8,7 @@
  *
  *
  * IDENTIFICATION
- *   $PostgreSQL: pgsql/src/backend/tcop/pquery.c,v 1.134 2010/01/02 16:57:52 momjian Exp $
+ *   $PostgreSQL: pgsql/src/backend/tcop/pquery.c,v 1.135 2010/02/13 22:45:41 momjian Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -1318,9 +1318,14 @@ PortalRunMulti(Portal portal, bool isTopLevel,
     * If a command completion tag was supplied, use it.  Otherwise use the
     * portal's commandTag as the default completion tag.
     *
-    * Exception: clients will expect INSERT/UPDATE/DELETE tags to have
-    * counts, so fake something up if necessary.  (This could happen if the
-    * original query was replaced by a DO INSTEAD rule.)
+    * Exception: Clients expect INSERT/UPDATE/DELETE tags to have
+    * counts, so fake them with zeros.  This can happen with DO INSTEAD
+    * rules if there is no replacement query of the same type as the
+    * original.  We print "0 0" here because technically there is no
+    * query of the matching tag type, and printing a non-zero count for
+    * a different query type seems wrong, e.g.  an INSERT that does
+    * an UPDATE instead should not print "0 1" if one row
+    * was updated.  See QueryRewrite(), step 3, for details.
     */
    if (completionTag && completionTag[0] == '\0')
    {