On Thu, Sep 06, 2001 at 03:16:26PM -0400, Tom Lane wrote: > [EMAIL PROTECTED] 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? Thanks for the clear explanation. I see now. Well -- I think either behavior is a little strange, so I'd go for the one you think best for the moment and stick with it, putting on a big red warning sign ;-) My pattern of use for ``CREATE RULE... NOTIFY...'' was, up to now, to get a notice when anything changed on a table and then go look what happened; a `poor man's statement level trigger' if you wish. Thus, the old behavior didn't bother me that much. I don't know how others are using it. Come to think of it, the CREATE RULE ``triggers'' on statements anyway -- it looks at the parsed statement and is independent of the actual content of the database: so the old behaviour seems a bit more natural to me: ``Look: someone has called an UPDATE on this table: I don't know whether it is going to hit any records, but...'' the CREATE RULE acts then as a kind of `qualifier barrier' and therefore the NOTIFY doesn't see it. What do you think? Thanks again for your great work Cheers -- tomas ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
