From 17c03b30b0f191e62e992dc6af8c995fd2b007a2 Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Fri, 7 Sep 2001 20:52:31 +0000 Subject: [PATCH] Revert treatment of NOTIFY in rules to its pre-7.1 behavior: notify will occur unconditionally, even if the rule should otherwise execute conditionally. This is more useful than giving an error, even though it's not truly the correct behavior. Per today's pghackers discussion. --- doc/src/sgml/ref/create_rule.sgml | 16 +++++++++++++++- 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 4d682c8899..47c029e653 100644 --- a/doc/src/sgml/ref/create_rule.sgml +++ b/doc/src/sgml/ref/create_rule.sgml @@ -1,5 +1,5 @@ @@ -249,6 +249,20 @@ SELECT * FROM emp; + + + 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 + +CREATE RULE notify_me AS ON UPDATE TO mytable DO NOTIFY mytable; + +UPDATE mytable SET name = 'foo' WHERE id = 42; + + 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. + diff --git a/src/backend/rewrite/rewriteManip.c b/src/backend/rewrite/rewriteManip.c index 45115b8d04..238897d58e 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. * - * For now, we expect utility stmt to be a NOTIFY, so give a specific - * error message for that case. + * 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. + * + * 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"); }