RE: [HACKERS] Rules: first fix on monday
От | Keith Parks |
---|---|
Тема | RE: [HACKERS] Rules: first fix on monday |
Дата | |
Msg-id | 199808181759.SAA11300@mtcc.demon.co.uk обсуждение исходный текст |
Список | pgsql-hackers |
Stupor Genius <stuporg@erols.com> > > > 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. Ah, yes, I remember, the 8k limit. > > 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. Another table would be the answer, and no need to have it cached. > > 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. > I use Oracle at work and I must admit I find the views useful. It seems quite natural to use SQL to to look at these things and views to combine information. Keith.
В списке pgsql-hackers по дате отправления: