On Thu, Sep 06, 2001 at 03:16:26PM -0400, Tom Lane wrote:
> 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?
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
