Jan Wieck <JanWieck@Yahoo.com> writes:
> Dave Page wrote:
>> Would it be possible and sensible to store the original view definition
>> for future use, such as we do for functions? Perhaps a new catalog
>> (pg_source?) could store these and other definitions such as rules for
>> use?
> Not too obvious, but this should be covered in the TODO item "Allow RULE
> recompilation". That is because if the rule/view is broken due to other
> schema changes, the reconstruction might fail.
Given the dependency mechanism in 7.3, it should no longer be possible
to break a rule that way. Of course, there are cases where you'd wish
the rule to *change* not just reject the update.
The major problem with any such proposal is that source-form storage has
its own set of inflexibilities. For example, we can currently allow
renaming of tables and columns that underlie a view, because the stored
form of the view doesn't contain those names and so it doesn't need to
change. If we store source text then we'd have to forbid such renaming
--- or else update the source text, which seems to require parsing,
adjustment of parsed tree, deparsing; which rather defeats the purpose
of Dave's request.
There are even more subtle problems: the source text may be ambiguous
in some way, so that reparsing it today might not generate the identical
intepretation to what you had before. Even "a+b" is ambiguous given
the possibility that user-defined operators could be added, or the
search path changed. Deparsing compensates for this by producing (or
at least trying to produce) a representation that is correct and
unambiguous in the current context.
One reason I'm disillusioned with this idea is that we do take the
trouble to store both source and internal form of column default
expressions, but in practice pg_attrdef.adsrc has fallen into disuse.
That track record doesn't bode well for adding source-form storage of
other things.
regards, tom lane
