Bogus use of *-expansion in UPDATE

You get an odd result if you write "something.*" in an UPDATE's
source expressions:

regression=# create table t1 (f1 int, f2 int, f3 int);
CREATE TABLE
regression=# update t1 set f1 = t1.*;
ERROR:  UPDATE target count mismatch --- internal error

The reason for that is that we use transformTargetList() to do
parse analysis of the source expressions, and it thinks it should
expand "t1.*" into "t1.f1, t1.f2, t1.f3" as we would do in a SELECT.
This seems nonsensical to me: there is no way that there can be
more than one source expression for a given target column.

It would make sense to do *-expansion in this context:

regression=# update t1 set (f1,f2,f3) = (t1.*);

since that's implicitly a row constructor and we're supposed to do
*-expansion in row constructors.  Currently it doesn't work:

ERROR:  number of columns does not match number of values
LINE 1: update t1 set (f1,f2,f3) = (t1.*);                                  ^

which I think is a separate bug, or at least missing feature, in the
multi-target-column feature.  It would take a little work to fix
that, since the expansion would have to wait till parse analysis,
whereas currently we separate the column targets in gram.y.

In short, I think we should modify transformTargetList so that it
doesn't do *-expansion when processing a simple UPDATE SET expression.
I'm not sufficiently motivated to rewrite the code enough to fix the
second case right now, but the first case seems like a simple
bug fix.  I would expect
UPDATE tab SET composite_column = foo.*

to be capable of working, but right now it's busted.
        regards, tom lane