RE: [HACKERS] Rules: first fix on monday
От | Stupor Genius |
---|---|
Тема | RE: [HACKERS] Rules: first fix on monday |
Дата | |
Msg-id | 000401bdca33$038a9ac0$d29daccf@darren обсуждение исходный текст |
Ответ на | Re: [HACKERS] Rules: first fix on monday (Keith Parks <emkxp01@mtcc.demon.co.uk>) |
Ответы |
Re: [HACKERS] Rules: first fix on monday
Re: [HACKERS] Rules: first fix on monday Re: [HACKERS] Rules: first fix on monday |
Список | 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 по дате отправления: