Andres Freund <andres@anarazel.de> writes:
> 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.
Hm. Since index tuples lack any means of indicating the actual number
of columns included (ie there's no equivalent of the natts field that
exists in HeapTupleHeaders), I think that this is an unreasonably
dangerous design. It'd be better to store nulls for the missing
fields. That would force a null bitmap to be included whether or
not there were nulls in the key columns, but if we're only doing it
once per page that doesn't seem like much cost.
>> 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).
Ah, I see. But in that case you're not really truncating the tuple
--- what you want is to be allowed to pass undersized datum/nulls
arrays and have the missing columns be taken as nulls.
In short, I'd be okay with an extension that allows shortened input
arrays, but I think it needs to produce fully valid tuples with nulls
in the unsupplied columns. (In the heap case we could indeed achieve
that effect by storing the smaller natts value in the header, but not
in the index case.)
regards, tom lane
