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@debis.com (Jan Wieck) #

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)