I have updated the attached C comment about why we return "0 0" for some
tags.
--
Bruce Momjian <br...@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Index: src/backend/tcop/pquery.c
===================================================================
RCS file: /cvsroot/pgsql/src/backend/tcop/pquery.c,v
retrieving revision 1.134
diff -c -c -r1.134 pquery.c
*** src/backend/tcop/pquery.c 2 Jan 2010 16:57:52 -0000 1.134
--- src/backend/tcop/pquery.c 13 Feb 2010 22:45:08 -0000
***************
*** 1318,1326 ****
* 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.)
*/
if (completionTag && completionTag[0] == '\0')
{
--- 1318,1331 ----
* If a command completion tag was supplied, use it. Otherwise use the
* portal's commandTag as the default completion tag.
*
! * 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')
{
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
