Re: non instead rule system

>
> 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.

Until later, Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck(at)debis(dot)com (Jan Wieck) #