Thread: 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

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