Re: [HACKERS] Rules: first fix on monday
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] Rules: first fix on monday |
Дата | |
Msg-id | 199808180106.VAA01045@candle.pha.pa.us обсуждение исходный текст |
Ответ на | RE: [HACKERS] Rules: first fix on monday ("Stupor Genius" <stuporg@erols.com>) |
Список | pgsql-hackers |
[Charset iso-8859-1 unsupported, filtering to ASCII...] > > 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. Obviously the real fix is for larger block sizes. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
В списке pgsql-hackers по дате отправления: