Tom Lane wrote:
> "Steve Howe" <howe@carcass.dhs.org> writes:
> > create rule blah_update as
> > on update to blah
> > do
> > notify TestEvent;
>
> > UPDATE blah SET n1=n1+1; -- Won't crash the connection
> > UPDATE blah SET n1=2 WHERE var_field='aaa' AND n1=1 AND n2=2 AND arr_str IS
> > NULL AND m IS NULL; -- Will crash the connection
>
> The problem here is that the query rewriter tries to hang the query's
> qualification (WHERE clause) onto the rule's action query, so that
> the action query won't be done unless the query finds at least one
> row to update.
>
> NOTIFY commands, being utility statements, don't have qualifications.
> In 7.0 and before, the qual clause just vanished into the ether, and
> so in this example the NOTIFY would execute whether the UPDATE updated
> any rows or not. In 7.1 there is physically noplace to hang the qual
> (no jointree) and thus a crash.
>
> Not sure what to do here. Adding quals to utility statements is right
> out, however --- even if we weren't late in beta, the concept doesn't
> make any sense to me. For one reason, utility statements don't have
> FROM clauses against which to evaluate the quals. I am leaning to the
> idea that we should forbid NOTIFY in rules altogether. Jan, what's your
> thought?
>
> Steve, your immediate move is to use a trigger rather than a rule to
> execute the NOTIFY. Meanwhile, we have to think about what to do...
Would be something for a STATEMENT trigger. We don't have 'em yet and I'm not sure what kind of information
they will receive if we finally implement them. But the number of rows affected by the statement is a good
candidate.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com