From: | Brandon Craig Rhodes <brandon(at)oit(dot)gatech(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: bug? rules fail to cascade after NOT IN |
Date: | 2003-03-04 04:01:11 |
Message-ID: | w6r89n7pbs.fsf@guinness.ts.gatech.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> While rule-as-macro works beautifully for views, I've never been
> entirely satisfied with it for updating queries. ... It would take a
> rather fundamental redesign of the rule system to do differently,
> though. Are you volunteering?
From what I have seen of the planner, its plans look like a funnel -
operator results are repeatedly combined until the result narrows to
exactly the rows specified by the user. But if NEW and OLD are to
truly become the tuples that were inserted, updated, or deleted, then
plans might being to look like trees that, after combining into a
trunk, start branching out again to form roots - because the resulting
rows will not only be, say, inserted into a table, but might be shared
between several rules that will then have their own operations to
perform upon the result.
And yes, I am volunteering. :-)
--
Brandon Craig Rhodes http://www.rhodesmill.org/brandon
Georgia Tech brandon(at)oit(dot)gatech(dot)edu
From | Date | Subject | |
---|---|---|---|
Next Message | Chris Sutton | 2003-03-04 15:03:59 | Best setup for RAM drive |
Previous Message | Tom Lane | 2003-03-04 03:45:46 | Re: bug? rules fail to cascade after NOT IN |