Robert Haas <robertmhaas@gmail.com> writes:
> What exactly do you mean by "re-parse the current view definition"?
> The only form of the view definition we actually have is already
> parsed into an internal form (see pg_rewrite) which, for the reasons
> I've attempted to explain, is not easy to adapt to new column types.
> I suppose we could deparse that definition and then reparse the
> results, but that could lead to some very surprising consequences
> (some of which are security-relevant).
Note that even if we had the original CREATE VIEW text, as well as
the creation-time settings of all relevant GUCs (search_path being
the most obvious, but not the only one), reparsing like this could
still be risky; it's not the conversion to internal form that's the
real issue here.
A simple example is that x || 'foo'
means something quite different if x is a tsvector than if x is text,
and something different from those if x is an array, and something
different yet again if x is bit varying. Some of those meanings
are close enough that the user might have wanted the substitution,
but others perhaps not.
Or for another example, if we have foo(x) calling foo(int),
and x's type is changed from int4 to int8, should we insert a
cast so that the same foo() is still called? Or should we allow
the called function to be replaced by foo(int8), foo(numeric),
foo(float8), if one of those exist?
I see the OP's point that the user is likely to try a naive manual
conversion first, but at least then it's on his head to be aware
of whether he got the semantics he wants.
regards, tom lane
