Re: Rule system goes weird with SELECT queries

"Kevin O'Gorman" <kogorman@pacbell.net> writes:
> If I define two rules for the same action, each with 
> a single select command, I wind up with two selects as
> expected, but they are both cross-product selects on the
> two tables. This is unexpected.

Rangetable leakage, sounds like --- the two queries are sharing the same
list of rangetable entries, and that's what the planner joins over.  Not
sure if it's *good* that they share the same rtable list, or if that's a
bug.  In any event, it's old news because current sources don't use the
rtable list to control joining; now there is a separate join tree, which
is definitely not shared.  I get

regression=# create rule rule4a as on insert to dummy do instead select * from
d2;
CREATE
regression=# create rule rule4b as on insert to dummy do instead select * from
d3;
CREATE
regression=# explain insert into dummy values(1);
NOTICE:  QUERY PLAN:

Seq Scan on d2  (cost=0.00..20.00 rows=1000 width=4)

NOTICE:  QUERY PLAN:

Seq Scan on d3  (cost=0.00..20.00 rows=1000 width=4)

EXPLAIN

which looks fine.  Can't check your other example, since the grammar
file hasn't been changed to allow it...

I'm not sure whether to recommend that you work from current CVS sources
or not.  A couple weeks ago that's what I would have said, but Vadim is
halfway through integrating WAL changes and I'm not sure how stable the
tip really is.  You could try the tip, and if it blows up fall back to
a dated retrieval from about 7-Oct.  Or you could investigate the way
that the 7.0.* rewriter handles the rtable list for multiple queries,
but that's probably not a real profitable use of your time.
        regards, tom lane