Andres Freund <and...@anarazel.de> writes: > On 2017-03-31 13:44:52 -0400, Tom Lane wrote: >> Andres Freund <and...@anarazel.de> writes: >>> The covering indexes patch  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 -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers