Re: This script will crash the connection

From: Jan Wieck <janwieck(at)Yahoo(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Steve Howe <howe(at)carcass(dot)dhs(dot)org>, Jan Wieck <JanWieck(at)Yahoo(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: This script will crash the connection
Date: 2001-01-24 22:35:54
Message-ID: 200101242235.RAA02720@jupiter.greatbridge.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> "Steve Howe" <howe(at)carcass(dot)dhs(dot)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(at)Yahoo(dot)com #

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nick Gorham 2001-01-24 22:37:52 Re: Re: unixODBC again :-(
Previous Message Norman J. Clarke 2001-01-24 22:21:00 Re: MySQL has transactions