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(at)alumni(dot)caltech(dot)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