Jimmy Yih <jyih@pivotal.io> writes:
> A colleague and I were playing around with dumping views and found an
> inconsistency for a view definition involving subqueries and undecorated
> constants in a UNION. When we took that view definition and restored it,
> dumping the view gave different syntax again. Although the slightly
> different view definitions were semantically the same, it was weird to see
> the syntax difference.
Yeah, this is a consequence of deciding to emit the explicit cast even
though there was none there to begin with. In many cases we have to do
that to ensure that the view will re-parse with the same semantics, but
I wonder if it would be possible to suppress it for top-level SELECT
list items. That would get rid of both stages of the apparent view
mutation not just one. The question that requires thought is whether
the view could ever re-parse differently, but offhand it seems like it
could not: there's only one rule for what an implicitly typed constant
could become in that situation.
> Looking at the internal code (mostly get_from_clause_item() function), we
> saw that when a subquery is used, there is no tuple descriptor passed to
> get_query_def() function. Because of this, get_target_list() uses the
> resnames obtained from the pg_rewrite entry's ev_action field. However, it
> seems to be fairly simple to construct a dummy tuple descriptor from the
> ev_action to pass down the call stack so that the column names will be
> consistent when deparsing both T_A_Const and T_TypeCast parse tree nodes
> involving a UNION. Attached is a patch that demonstrates this.
I'm afraid that this just moves the weird cases somewhere else, ie
you might see an AS clause where you had none before, or a different
AS clause from what you originally wrote. The parser has emitted the
same parse tree as if there were an explicit AS there; I doubt that
we want ruleutils to second-guess that unless it really has to.
regards, tom lane