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

Re: bug? rules fail to cascade after NOT IN

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Brandon Craig Rhodes <brandon(at)oit(dot)gatech(dot)edu>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: bug? rules fail to cascade after NOT IN
Date: 2003-03-04 03:45:46
Message-ID: 20168.1046749546@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Brandon Craig Rhodes <brandon(at)oit(dot)gatech(dot)edu> writes:
> If I understand your assertion, NEW does *not* in fact refer strictly
> to the rows that (in this case) were INSERTed by the upstream query;
> rather, NEW refers to a re-invocation - a copy or re-execution - of
> the query which produced the NEW rows themselves.

That's about the size of it.  A rule is a macro, and so is NEW (or OLD).

While rule-as-macro works beautifully for views, I've never been
entirely satisfied with it for updating queries.  Hardly anyone is able
to wrap their minds around the behavior, and all too often the only
workable solution is to use triggers instead --- which, as you say,
could be a performance loss when many rows have to be processed.  Even
if it's not a performance loss, one comes away wondering whether the
rule system is really doing the most useful thing.

It would take a rather fundamental redesign of the rule system to do
differently, though.  Are you volunteering?

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Brandon Craig RhodesDate: 2003-03-04 04:01:11
Subject: Re: bug? rules fail to cascade after NOT IN
Previous:From: Brandon Craig RhodesDate: 2003-03-04 03:23:43
Subject: Re: bug? rules fail to cascade after NOT IN

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