Re: [HACKERS] View definition formatting

Thanks for the responses. I guess I'm going to have to write some view
formatting code... :-(
Oh well, at least it's for a good reason!!

Regards, Dave

It's rumoured that Tom Lane once said:
> Jan Wieck <JanWieck(at)Yahoo(dot)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