Skip site navigation (1) Skip section navigation (2)

Re: Conditional NOTIFY is not implemented

From: tomas(at)fabula(dot)de
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: tomas(at)fabula(dot)de, pgsql-hackers(at)postgreSQL(dot)org, pgsql-bugs(at)postgreSQL(dot)org, matthew(dot)copeland(at)honeywell(dot)com
Subject: Re: Conditional NOTIFY is not implemented
Date: 2001-09-07 04:10:01
Message-ID: 20010907061001.A24665@www (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-hackers
On Thu, Sep 06, 2001 at 03:16:26PM -0400, Tom Lane wrote:
> tomas(at)fabula(dot)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

In response to

Responses

pgsql-hackers by date

Next:From: Joe ConwayDate: 2001-09-07 04:23:21
Subject: Re: byteain bug(?)
Previous:From: Tom LaneDate: 2001-09-07 04:09:32
Subject: Re: byteain bug(?)

pgsql-bugs by date

Next:From: Tom LaneDate: 2001-09-07 04:30:44
Subject: Re: Conditional NOTIFY is not implemented
Previous:From: Marc G. FournierDate: 2001-09-07 03:32:12
Subject: pgsql/src/backend/utils/mb encnames.c win1251. ...

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group