Re: When do we lose column names?

I wrote:
> and the issue seems to be that in execution of a RowExpr, the
> executor doesn't pay any attention to preserving the column names
> in the generated tupledesc --- see the ExecTypeFromExprList call
> in execQual.c. ...
> We could certainly make it do that --- it wouldn't even be terribly
> hard, since RowExpr already does store the column names. ...
> (wanders off to look at whether the only other caller of
> ExecTypeFromExprList could be taught to provide useful field names...)

PFC, a patch that does this. This seems to fix Andrew's issue with
respect to the RowExpr case. It's not really ideal with respect to
the ValuesScan case, because what you get seems to always be the
hard-wired "columnN" names for VALUES columns, even if you try to
override that with an alias:

regression=# select each(hstore(q)) as x
from (values (1,2,3),(4,5,6) limit 2) as q(x,y,z);
x
-------------
(column1,1)
(column2,2)
(column3,3)
(column1,4)
(column2,5)
(column3,6)
(6 rows)

I think this happens because VALUES in a FROM item is treated like a
sub-select, and the aliases are getting applied at the "wrong" level.
Don't know if that's worth trying to fix, or how hard it would be.
Curiously, it works just fine if the VALUES can be folded:

regression=# select each(hstore(q)) as x
from (values (1,2,3),(4,5,6)) as q(x,y,z);
x
-------
(x,1)
(y,2)
(z,3)
(x,4)
(y,5)
(z,6)
(6 rows)

regards, tom lane