FOUND patch was a bit over-enthusiastic: SQL commands that are not

INSERT, UPDATE, or DELETE shouldn't change FOUND.  IMHO anyway.
Also, try to make documentation a little clearer.

doc/src/sgml/plpgsql.sgml

@@ -1,5 +1,5 @@
 <!--
-$Header: /cvsroot/pgsql/doc/src/sgml/plpgsql.sgml,v 1.3 2002/08/22 00:01:40 tgl Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/plpgsql.sgml,v 1.4 2002/08/29 04:12:02 tgl Exp $
 -->
 
 <chapter id="plpgsql"> 
@@ -852,58 +852,10 @@ SELECT INTO <replaceable>target</replaceable> <replaceable>expressions</replacea
     </para>
 
     <para>
-	 There is a special variable named <literal>FOUND</literal> of
+     You can use <literal>FOUND</literal> immediately after a SELECT
-     type <type>boolean</type>. The initial value of
+     INTO statement to determine whether the assignment was successful
-     <literal>FOUND</literal> is false; it is set to true when one of
+     (that is, at least one row was was returned by the SELECT
-     the following events occurs:
+     statement). For example:
-	 <itemizedlist>
-	  <listitem>
-	   <para>
-		A SELECT INTO statement is executed, and it returns one or
-		more rows.
-	   </para>
-	  </listitem>
-	  <listitem>
-	   <para>
-		A UPDATE, INSERT, or DELETE statement is executed, and it
-		affects one or more rows.
-	   </para>
-	  </listitem>
-	  <listitem>
-	   <para>
-		A PERFORM statement is executed, and it discards one or more
-		rows.
-	   </para>
-	  </listitem>
-	  <listitem>
-	   <para>
-		A FETCH statement is executed, and it returns an additional
-		row.
-	   </para>
-	  </listitem>
-	  <listitem>
-	   <para>
-		A FOR statement is executed, and it iterates one or more
-		times. This applies to all three variants of the FOR statement
-		(integer FOR loops, record-set FOR loops, and dynamic
-		record-set FOR loops). <literal>FOUND</literal> is only set
-		when the FOR loop exits: inside the execution of the loop,
-		<literal>FOUND</literal> is not modified, although it may be
-		set by the execution of other statements.
-	   </para>
-	  </listitem>
-	 </itemizedlist>
-	 If none of these events occur, <literal>FOUND</literal> is set to
-	 false. <literal>FOUND</literal> is a local variable; any changes
-	 to it effect only the current <application>PL/pgSQL</application>
-	 function.
-	</para>
-
-	<para>
-	 You can use <literal>FOUND</literal> immediately after a SELECT
-	 INTO statement to determine whether the assignment was successful
-	 (that is, at least one row was was returned by the SELECT
-	 statement). For example:
   
 <programlisting>
 SELECT INTO myrec * FROM EMP WHERE empname = myname;
@@ -1116,6 +1068,58 @@ GET DIAGNOSTICS <replaceable>variable</replaceable> = <replaceable>item</replace
 </programlisting>
 </informalexample>
     </para>
+
+    <para>
+     There is a special variable named <literal>FOUND</literal> of
+     type <type>boolean</type>.  <literal>FOUND</literal> starts out
+     false within each <application>PL/pgSQL</application> function.
+     It is set by each of the following types of statements:
+	 <itemizedlist>
+	  <listitem>
+	   <para>
+		A SELECT INTO statement sets <literal>FOUND</literal>
+		true if it returns a row, false if no row is returned.
+	   </para>
+	  </listitem>
+	  <listitem>
+	   <para>
+		A PERFORM statement sets <literal>FOUND</literal>
+		true if it produces (discards) a row, false if no row is
+		produced.
+	   </para>
+	  </listitem>
+	  <listitem>
+	   <para>
+		UPDATE, INSERT, and DELETE statements set
+		<literal>FOUND</literal> true if at least one row is
+		affected, false if no row is affected.
+	   </para>
+	  </listitem>
+	  <listitem>
+	   <para>
+		A FETCH statement sets <literal>FOUND</literal>
+		true if it returns a row, false if no row is returned.
+	   </para>
+	  </listitem>
+	  <listitem>
+	   <para>
+		A FOR statement sets <literal>FOUND</literal>
+		true if it iterates one or more times, else false.
+		This applies to all three variants of the FOR statement
+		(integer FOR loops, record-set FOR loops, and dynamic
+		record-set FOR loops). <literal>FOUND</literal> is only set
+		when the FOR loop exits: inside the execution of the loop,
+		<literal>FOUND</literal> is not modified by the FOR statement,
+		although it may be changed by the execution of other
+		statements within the loop body.
+	   </para>
+	  </listitem>
+	 </itemizedlist>
+     <literal>FOUND</literal> is a local variable; any changes
+     to it affect only the current <application>PL/pgSQL</application>
+     function.
+    </para>
+
    </sect2>
   </sect1>
 

src/pl/plpgsql/src/pl_exec.c

@@ -3,7 +3,7 @@
  *			  procedural language
  *
  * IDENTIFICATION
- *	  $Header: /cvsroot/pgsql/src/pl/plpgsql/src/pl_exec.c,v 1.58 2002/08/24 15:00:47 tgl Exp $
+ *	  $Header: /cvsroot/pgsql/src/pl/plpgsql/src/pl_exec.c,v 1.59 2002/08/29 04:12:03 tgl Exp $
  *
  *	  This software is copyrighted by Jan Wieck - Hamburg.
  *
@@ -1844,11 +1844,6 @@ exec_stmt_execsql(PLpgSQL_execstate * estate,
 	PLpgSQL_expr *expr = stmt->sqlstmt;
 	bool		isnull;
 
-	/*
-	 * Set magic FOUND variable to false
-	 */
-	exec_set_found(estate, false);
-
 	/*
 	 * On the first call for this expression generate the plan
 	 */
@@ -1927,16 +1922,15 @@ exec_stmt_execsql(PLpgSQL_execstate * estate,
 		case SPI_OK_SELINTO:
 			break;
 
+		case SPI_OK_INSERT:
+		case SPI_OK_DELETE:
+		case SPI_OK_UPDATE:
 			/*
 			 * If the INSERT, DELETE, or UPDATE query affected at least
 			 * one tuple, set the magic 'FOUND' variable to true. This
 			 * conforms with the behavior of PL/SQL.
 			 */
-		case SPI_OK_INSERT:
+			exec_set_found(estate, (SPI_processed != 0));
-		case SPI_OK_DELETE:
-		case SPI_OK_UPDATE:
-			if (SPI_processed > 0)
-				exec_set_found(estate, true);
 			break;
 
 		case SPI_OK_SELECT: