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