From bbdf72b095f646c85b572677376692a47924e3fc Mon Sep 17 00:00:00 2001
From: Bruce Momjian <bruce@momjian.us>
Date: Sat, 13 Feb 2010 22:45:41 +0000
Subject: [PATCH] Improve C comment about why we return "0 0" for some tags.
---
src/backend/tcop/pquery.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/src/backend/tcop/pquery.c b/src/backend/tcop/pquery.c
index 05068fa406c..42960b82250 100644
--- a/src/backend/tcop/pquery.c
+++ b/src/backend/tcop/pquery.c
@@ -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')
{
--
GitLab