diff --git a/doc/src/sgml/ref/create_rule.sgml b/doc/src/sgml/ref/create_rule.sgml
index 4d682c8899a37ba561e5f9dfbe09f2075676e718..47c029e653d96092de4475f198b5f5f51f7c188e 100644
--- a/doc/src/sgml/ref/create_rule.sgml
+++ b/doc/src/sgml/ref/create_rule.sgml
@@ -1,5 +1,5 @@
 <!--
-$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_rule.sgml,v 1.25 2001/09/03 12:57:49 petere Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_rule.sgml,v 1.26 2001/09/07 20:52:30 tgl Exp $
 Postgres documentation
 -->
 
@@ -249,6 +249,20 @@ SELECT * FROM emp;
       </programlisting></para>
     </example>
    </para>
+
+   <para>
+    Presently, if a rule contains a NOTIFY query, the NOTIFY will be executed
+    unconditionally --- that is, the NOTIFY will be issued even if there are
+    not any rows that the rule should apply to.  For example, in
+      <programlisting>
+CREATE RULE notify_me AS ON UPDATE TO mytable DO NOTIFY mytable;
+
+UPDATE mytable SET name = 'foo' WHERE id = 42;
+      </programlisting>
+    one NOTIFY event will be sent during the UPDATE, whether or not there
+    are any rows with id = 42.  This is an implementation restriction that
+    may be fixed in future releases.
+   </para>
   </refsect2>
  </refsect1>
 
diff --git a/src/backend/rewrite/rewriteManip.c b/src/backend/rewrite/rewriteManip.c
index 45115b8d045e3cc26803fa5f2d5993e7f0703b7c..238897d58ebd7dfd41c1cd09de5688e660436500 100644
--- a/src/backend/rewrite/rewriteManip.c
+++ b/src/backend/rewrite/rewriteManip.c
@@ -7,7 +7,7 @@
  *
  *
  * IDENTIFICATION
- *	  $Header: /cvsroot/pgsql/src/backend/rewrite/rewriteManip.c,v 1.57 2001/04/18 20:42:55 tgl Exp $
+ *	  $Header: /cvsroot/pgsql/src/backend/rewrite/rewriteManip.c,v 1.58 2001/09/07 20:52:31 tgl Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -592,15 +592,21 @@ AddQual(Query *parsetree, Node *qual)
 
 	if (parsetree->commandType == CMD_UTILITY)
 	{
-
 		/*
-		 * Noplace to put the qual on a utility statement.
+		 * There's noplace to put the qual on a utility statement.
+		 *
+		 * If it's a NOTIFY, silently ignore the qual; this means that the
+		 * NOTIFY will execute, whether or not there are any qualifying rows.
+		 * While clearly wrong, this is much more useful than refusing to
+		 * execute the rule at all, and extra NOTIFY events are harmless for
+		 * typical uses of NOTIFY.
 		 *
-		 * For now, we expect utility stmt to be a NOTIFY, so give a specific
-		 * error message for that case.
+		 * If it isn't a NOTIFY, error out, since unconditional execution
+		 * of other utility stmts is unlikely to be wanted.  (This case is
+		 * not currently allowed anyway, but keep the test for safety.)
 		 */
 		if (parsetree->utilityStmt && IsA(parsetree->utilityStmt, NotifyStmt))
-			elog(ERROR, "Conditional NOTIFY is not implemented");
+			return;
 		else
 			elog(ERROR, "Conditional utility statements are not implemented");
 	}
@@ -634,15 +640,13 @@ AddHavingQual(Query *parsetree, Node *havingQual)
 
 	if (parsetree->commandType == CMD_UTILITY)
 	{
-
 		/*
-		 * Noplace to put the qual on a utility statement.
+		 * There's noplace to put the qual on a utility statement.
 		 *
-		 * For now, we expect utility stmt to be a NOTIFY, so give a specific
-		 * error message for that case.
+		 * See comments in AddQual for motivation.
 		 */
 		if (parsetree->utilityStmt && IsA(parsetree->utilityStmt, NotifyStmt))
-			elog(ERROR, "Conditional NOTIFY is not implemented");
+			return;
 		else
 			elog(ERROR, "Conditional utility statements are not implemented");
 	}