"Andrew Dunstan" <and...@dunslane.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 -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers