RE: [HACKERS] Rules: first fix on monday - Mailing list pgsql-hackers

From Stupor Genius
Subject RE: [HACKERS] Rules: first fix on monday
Date
Msg-id 000401bdca33$038a9ac0$d29daccf@darren
Whole thread Raw
In response to Re: [HACKERS] Rules: first fix on monday  (Keith Parks <emkxp01@mtcc.demon.co.uk>)
Responses Re: [HACKERS] Rules: first fix on monday  (Bruce Momjian <maillist@candle.pha.pa.us>)
Re: [HACKERS] Rules: first fix on monday  (dg@informix.com (David Gould))
Re: [HACKERS] Rules: first fix on monday  (jwieck@debis.com (Jan Wieck))
List pgsql-hackers
> 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.

Adding a column will take away from the already-tight space needed
to keep the plan.

Perhaps a better way is to have a new non-cached system table that
would be joined to pg_rewrite to show the plain-text plan when needed.

Rather than require the user to know this join, postgres could (or
should) have some system views (ala Oracle) to hide the underlying
table structures and prevent any user except the superuser from
modifying a system table without using a postgres command.

darrenk

pgsql-hackers by date:

Previous
From: Keith Parks
Date:
Subject: Re: [HACKERS] Rules: first fix on monday
Next
From: The Hermit Hacker
Date:
Subject: Re: [HACKERS] Rules: first fix