Re: [HACKERS] Rules: first fix on monday

Tom, Jan,

These were my thought too.

We could add another column to "pg_rewrite" which contained the
source for the rule. This could be used by pg_dump to dump the
rule creation statement, or by the user to see what the rule
actually does.

Perhaps someone who knows how to graft in new columns could do
that now before we finalise 6.4, even if we don't use it straight
away it would serve as a marker.

I believe a dump/restore is required for 6.3 to 6.4 so we might as
well get the catalog change in sooner rather than later.

Keith.


Thomas G. Lockhart <lockhart@alumni.caltech.edu>
>
> > > 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.
> >     Yes,  that  would really be nice and I had something the like
> >     already in mind.
> >     I'm not really sure if it's a good thing to  save  the  rules
> >     definition  text  instead of the parsetree. The advantages of
> >     doing so would be that the rule could easily  be  dumped  and
> >     (more  important)  that  the  rules can have more complicated
> >     actions (remember that the currently  stored  parsetrees  can
> >     quickly override the size limit of a text type).
> >
> >     Storing  the  definition  text only would require to parse at
> >     least the actions any time, a  rule  should  be  fired  on  a
> >     query.  Bad  for  performance - but must check if significant
> >     bad.
>
> How about storing both an internal form and the plain text source? That
> way you can use the fast form internally and dump the plain text...
>
>                       - Tom