diff options
| -rw-r--r-- | doc/src/sgml/ref/create_rule.sgml | 16 | ||||
| -rw-r--r-- | src/backend/rewrite/rewriteManip.c | 26 |
2 files changed, 30 insertions, 12 deletions
diff --git a/doc/src/sgml/ref/create_rule.sgml b/doc/src/sgml/ref/create_rule.sgml index 4d682c8899a..47c029e653d 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 45115b8d045..238897d58eb 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"); } |