> >
> > Jan wrote:
> > I think there is no choice any longer. I'll start now
> > removing all the non-instead rule stuff to make the rule
> > system as reliable as can.
> >
> > Is this really necessary to get the instead stuff working ? If not, I think
> > it would be good to keep it even if it is currently somewhat broken. Maybe someone
> > wants to look it over later. The rule system is one hell of a concept with lots of
> > diploma work at Berkeley behind it.
> >
> > Andreas
>
> After I started now, I don't think any longer that it is
> really necessary to remove all the non-instead stuff.
>
> The RIR rules work, that's why the views work. What's missing
> for the other rules (as far as I see it in the query
> debugging now) is that RIR rules also have to be applied on
> these queries first.
>
> Having a view, you might want to define an update instead
> rule that updates the real tables behind the view. The
> parsers output for an update on the view references the view
> itself in the rangetable and it's var nodes in targetList and
> qual. Before processing the update rule, these must first be
> substituted to what they really are (RTE's for the real
> tables and the targetList and qual expressions from the RIR
> rule of the view). As it is now, the query after rewriting
> still uses the view itself in the qual expressions. This
> results later in very complicated mergejoin and nestloop
> plans, that in fact do nothing because they scan the view
> somewhere and while thats an empty relation will never find a
> single row.
>
> I know now, that the RIR rules have to be taken to modify the
> queries for insert, update and delete commands. Let's see
> what happens if I got that and decide then how to move on.
The only thing I can add to this discussion is that I remember a lot of
dancing going on about why the rule system did not work, and the idea
that it was supposed to do X, Y, and Z, and that it could do X and Y,
but not Z. The issue I though was that the was an actual logic problem
about doing trying to do all three of them. Not a coding problem, but a
problem that it was not logically possible to do all three.
Maybe this makes no sense.
--
Bruce Momjian | 830 Blythe Avenue
maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)
