On 2017-03-31 13:44:52 -0400, Tom Lane wrote:
> 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.
The patch does actually store truncated/key-only tuples in the hi keys /
non-leaf-nodes, which don't need the "included" columns.
> > 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.
It'd be useful for FieldStore - we'd not have to error out anymore if
the number of columns changes (which I previously had "solved" by using
MaxHeapAttributeNumber sized values/nulls array).
Greetings,
Andres Freund
