Re: bug? rules fail to cascade after NOT IN - Mailing list pgsql-hackers

From Tom Lane
Subject Re: bug? rules fail to cascade after NOT IN
Date
Msg-id 20168.1046749546@sss.pgh.pa.us
Whole thread Raw
In response to Re: bug? rules fail to cascade after NOT IN  (Brandon Craig Rhodes <brandon@oit.gatech.edu>)
Responses Re: bug? rules fail to cascade after NOT IN  (Brandon Craig Rhodes <brandon@oit.gatech.edu>)
List pgsql-hackers
Brandon Craig Rhodes <brandon@oit.gatech.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


pgsql-hackers by date:

Previous
From: Brandon Craig Rhodes
Date:
Subject: Re: bug? rules fail to cascade after NOT IN
Next
From: Brandon Craig Rhodes
Date:
Subject: Re: bug? rules fail to cascade after NOT IN