Issues with dropped columns in views depending on functions

I looked into the problem described here:
http://www.postgresql.org/message-id/53C93986.80904@clickware.de

The core issue is that the ruleutils.c code isn't thinking about dropped
columns in the output of a function-in-FROM that returns a composite type.
Pre-9.3, there had been some code there to cope with the case by means of
doing a get_rte_attribute_is_dropped() test on each column as the alias
list was printed, but I'd lost that in the rewrite that improved handling
of column aliases in RTEs with dropped columns. I looked at putting that
back, but (a) it's slow, and (b) it didn't really work right even when it
was there: it only accidentally failed to crash in EXPLAIN's usage,
because we were applying exprType() to a null funcexpr field.

The next possibility that I looked at was teaching the code to ignore
empty-string items in a function RTE's alias list, since that's what
the parser inserts to correspond to dropped columns at parse time.
This solves the reported problem, almost, except that it exposed an
ancient bug in outfuncs/readfuncs: the code to print a T_String node is
wrong for the case of an empty string. What it actually prints is "<>"
which of course reads back as <>, not empty. After repairing that, I had
a patch that takes care of the reported problem, at least for newly
created views (see attached). It won't do anything to retroactively fix
the problem in existing views, but I think that might be okay given the
small number of complaints.

However, this only fixes the issue for columns that were dropped before
the view was created. The system will let you drop columns *after* the
view is created, and then we have a problem, as illustrated by the
rather dubious results in the regression test in the attached patch.
I'm of the opinion that this is a bug and we should disallow dropping
a composite type's column if it's explicitly referenced in any view, much
as would happen if there were a direct reference to the table. However,
that will take some nontrivial surgery on the dependency code, and I
rather doubt that we want to back-patch such a thing --- especially since
the needed pg_depend entries wouldn't be there anyway for existing views
in existing databases.

What I propose to do is apply the attached back through 9.3, so that at
least users are no worse off than they were pre-9.3. I will look at
fixing the problem of a post-view-creation column drop later, but I
suspect we'll end up not back-patching those changes.

regards, tom lane