Jan,

I'm absolutely amazed by this piece of magic.

I updated postrgreSQL from CVS, built postgres and the get_ruledef()
function and gave it a try.

A simple VIEW I have goes in as:-

  SELECT t.artist, t.song, t.trackno, d.cdname
  FROM disks d, tracks t
  WHERE d.diskid = t.diskid          
  
And comes out as :-

disks=> select get_ruledef('_RETsongs');
get_ruledef                                                                                                                                
--------------------------------------------------------------------------------
---------------------------------------------------------------------
CREATE RULE _RETsongs AS ON SELECT TO songs DO INSTEAD SELECT t.artist, t.song, 
t.trackno, d.cdname FROM disks d, tracks t WHERE d.diskid = t.diskid;
(1 row)

disks=>

Absolutely perfect rule definition for the VIEW.

One slight bug I found was that ANDs come out as ORs but that's
easily fixed with the following patch.

What can I say..... 
Thanks,
Keith.


*** get_ruledef/get_ruledef.c.orig	Tue Aug 18 19:34:34 1998
--- get_ruledef/get_ruledef.c	Tue Aug 18 19:34:53 1998
***************
*** 738,744 ****
  				strcat(buf, get_rule_expr(rtable, rt_index,
  					    (Node *)get_leftop(expr),
  					    varprefix));
! 				strcat(buf, ") OR (");
  				strcat(buf, get_rule_expr(rtable, rt_index,
  					    (Node *)get_rightop(expr),
  					    varprefix));
--- 738,744 ----
  				strcat(buf, get_rule_expr(rtable, rt_index,
  					    (Node *)get_leftop(expr),
  					    varprefix));
! 				strcat(buf, ") AND (");
  				strcat(buf, get_rule_expr(rtable, rt_index,
  					    (Node *)get_rightop(expr),
  					    varprefix));



jwieck@debis.com (Jan Wieck)
> >
> > > emkxp01@mtcc.demon.co.uk
> > > Jan,
> > >
> > > Whilst you are working on the rules system it would be nice if
> > > you could look for an oportunity to store the plain text rule
> > > definition at creation time.
> > >
> > > If the definition were stored in a table column it would allow us
> > > to dump and restore databases in a more complete way.
> > >
> > > I looked at this some while ago myself but never got close to
> > > making it work.
> > >
> > >    Keith.
> > >
> >
> >     Yes,  that  would really be nice and I had something the like
> >     already in mind.
> >
> > [...]
> >     On   the  other  hand  wouldn't  it  be  too  complicated  to
> >     reconstruct  a  command  from  the  parsetree,  that  exactly
> >     creates  the  rule.  Reading a parsetree isn't fun, but after
> >     all I did on the rewrite system I'm somewhat familiar with it
> >     now  (sometimes  I  see  the  cup in a targetlist, the coffee
> >     machine  in  the  rangetable  and  all  the  buttons  in  the
> >     qualification  when  pulling  a  coffee  out  of it - think I
> >     should I consult a psychist when the  rule  system  is  fixed
> >     :-).
> >
> >
> > Jan
> 
>     To  demonstrate  that  it really isn't that complicated as it
>     looks, here is a C function that if defined in the backend as
> 
>         CREATE FUNCTION get_ruledef(name)
>                 RETURNS text AS '.../get_ruledef.so'
>                 LANGUAGE 'C';
> 
>     can be used to see a textual representation of the rule given
>     as argument.


Tue, 18 Aug 1998 21:07:17 +0100 (BST)
Keith Parks <emkxp01@mtcc.demon.co.uk>
Re: [HACKERS] dumping rules
> 
> Jan,
> 
> I'm absolutely amazed by this piece of magic.

    Written just to check if I understand parsetrees now.

    :-)

> A simple VIEW I have goes in as:-
> 
>   SELECT t.artist, t.song, t.trackno, d.cdname
>   FROM disks d, tracks t
>   WHERE d.diskid = t.diskid          
>   
> And comes out as :-
> 
> disks=> select get_ruledef('_RETsongs');
> get_ruledef                                                                                                                                
> --------------------------------------------------------------------------------
> ---------------------------------------------------------------------
> CREATE RULE _RETsongs AS ON SELECT TO songs DO INSTEAD SELECT t.artist, t.song, 
> t.trackno, d.cdname FROM disks d, tracks t WHERE d.diskid = t.diskid;
> (1 row)
> 
> disks=>
> 
> Absolutely perfect rule definition for the VIEW.
> 
> One slight bug I found was that ANDs come out as ORs but that's
> easily fixed with the following patch.

    cut-n-paste error, tnx.

    Another one might be ISNULL (I think I missed it). But as I said,
    it's just a point to start from.

> 
> What can I say..... 
> Thanks,
> Keith.


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


Tue, 18 Aug 1998 22:18:51 +0200 (MET DST)
jwieck@debis.com (Jan Wieck)
Re: [HACKERS] dumping rules