Re: This script will crash the connection

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Steve Howe" <howe(at)carcass(dot)dhs(dot)org>
Cc: 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 05:57:08
Message-ID: 11137.980315828@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"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...

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Steve Leibel 2001-01-24 06:09:06 Re: MySQL has transactions
Previous Message Christopher Kings-Lynne 2001-01-24 05:52:53 RE: WAL documentation