tomas@fabula.de writes:
> versuch=# CREATE RULE ru_u_chkntfy AS ON UPDATE TO chkntfy DO NOTIFY CHKNTFY;
> CREATE
> versuch=# update chkntfy set nummer=10 where nummer = 1;
> ERROR: Conditional NOTIFY is not implemented
> Somehow the notify seems to take up the `where' qualifier of the query
> triggering the rule (you don't get the error message if you use an
> unqualified query).
> Is this considered a bug? Is a fix in sight?
Before 7.1, the system simply failed to account for the condition that
should be applied to the notify --- the notify ended up being fired all
the time, even if it shouldn't have been. In this case, the notify
should only occur if there are rows in chkntfy with nummer = 1 --- but
pre-7.1, it'd occur regardless. (We were rather fortunate to avoid a
crash, actually, since the code would attach a condition to a NOTIFY
querytree that should never have had one ... but then ignore it.)
Present behavior is to error out if the rewriter tries to attach a
nonempty condition to a NOTIFY query.
It'd be a simple code change to revert to the pre-7.1 behavior (notify
fires unconditionally), but actually making it work *correctly* is a
lot harder. NOTIFYs don't normally have any plan associated with them
at all, so there's no way to test a query condition.
Since we've seen several complaints about the new behavior, whereas
no one ever complained about excess NOTIFYs pre-7.1, perhaps the best
solution in the short run is to revert to the old behavior. We could
just document that NOTIFYs in rules are fired unconditionally.
Comments?
regards, tom lane