Обсуждение: Re: [BUGS] Conditional NOTIFY is not implemented

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

tomas@fabula.de writes:
> 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.

Yeah, that is the normal and recommended usage pattern for NOTIFY, so
getting a NOTIFY when nothing actually happened is fairly harmless.
(Undoubtedly that's why no one complained before.)

Changing the rewriter to error out when it couldn't really Do The Right
Thing seemed like a good idea at the time, but now it seems clear that
this didn't do anything to enhance the usefulness of the system.  Unless
someone objects, I'll change it back for 7.2.
        regards, tom lane

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