Re: When do we lose column names?

"Andrew Dunstan" <andrew(at)dunslane(dot)net> writes:
> What I'm having difficulty understanding is why the limit clause should
> make any difference.

Without the LIMIT, the query gets flattened to something like this:

Index Scan using pg_class_oid_index on pg_catalog.pg_class c
(cost=0.00..8.27 rows=1 width=202)
Output: ROW(c.oid, c.relname, c.relnamespace, c.reltype, c.reloftype, c.relowner, c.relam, c.relfilenode, c.reltablespace, c.relpages, c.reltuples, c.relallvisible, c.reltoastrelid, c.reltoastidxid, c.relhasindex, c.relisshared, c.relpersistence, c.relkind, c.relnatts, c.relchecks, c.relhasoids, c.relhaspkey, c.relhasrules, c.relhastriggers, c.relhassubclass, c.relfrozenxid, c.relacl, c.reloptions)
Index Cond: (c.oid = 53532::oid)

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. The only
downside I can see is that this might lead to more transient rowtypes
being kept around in a backend, since RowExprs with distinct field
names would now lead to different "blessed" rowtypes. But that doesn't
seem like a big deal. It was just never apparent before that we should
care about field names in a tupledesc at execution time.

I'm disinclined to consider this a back-patchable bug fix; it seems
possible that somebody out there is depending on the current behavior.
But we could think about changing it in HEAD.

(wanders off to look at whether the only other caller of
ExecTypeFromExprList could be taught to provide useful field names...)

regards, tom lane