Andres Freund <andres@anarazel.de> writes:
> The covering indexes patch [1] really needs a version of
> heap_form_tuple/index_form_tuple that allows to specify the number of
> columns in the to-be generated tuple.
I was thinking about that this morning, and wondering why exactly it
would need such a thing. Certainly we're not going to store such a
truncated tuple in the index, so I assume that the purpose here is
just to pass around the tuple internally for some reason. What's wrong
with just generating the full tuple, perhaps with nulls for the extra
columns if you're concerned about memory space?
> Previously the faster expression
> evaluation stuff could also have benefited form the same for both
> forming and deforming tuples.
Um, I didn't notice anyplace where that would have helped, certainly
not on the "form tuple" side. Tuples that don't meet their own tupdesc
don't seem to have wide application to me.
regards, tom lane