Re: Allow to specify #columns in heap/index_form_tuple

Peter Geoghegan <pg(at)bowt(dot)ie> writes:
> On Fri, Mar 31, 2017 at 2:11 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> 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.

> We're doing it once per page for the leaf page high key, but that's
> used as the downlink in the second phase of a B-Tree page split --
> it's directly copied. So, including a NULL bitmap would make
> Anastasia's patch significantly less useful,

I think you are failing to get the point. I am not on about whether
we need a few bytes more or less, I am on about whether the patch
even works. As an example, it's quite unclear what the width of
such an index tuple's nulls bitmap will be if it exists, and there
certainly will be cases where it must exist because of nulls in the
keys columns. I also think we're setting up a situation where tools
like amcheck and pg_filedump are going to be unable to cope, because
figuring out what a particular tuple contains is going to require context
they haven't got. It just seems way too dangerous.

regards, tom lane