Hi,
On 2019-04-22 13:27:17 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > The computation of that variable above has:
>
> > * If the column is possibly missing, we can't rely on its (or
> > * subsequent) NOT NULL constraints to indicate minimum attributes in
> > * the tuple, so stop here.
> > */
> > if (att->atthasmissing)
> > break;
>
> BTW, why do we have to stop? ISTM that a not-null column without
> atthasmissing is enough to prove this, regardless of the state of prior
> columns. (This is assuming that you trust attnotnull for this, which
> as I said I don't, but that's not relevant to this question.)
Are you wondering if we could also use this kind of logic to infer the
length of the null bitmap if there's preceding columns with
atthasmissing true as long as there's a later !hasmissing column that's
NOT NULL? Right. The logic could be made more powerful - I implemented
the above after Andrew's commit of fast-not-null broke JIT (not because
of that logic, but because it simply didn't look up the missing
columns). I assume it doesn't terribly matter to be fast once
attributes after a previously missing one are accessed - it's likely not
going to be the hotly accessed data?
> I wonder
> also if it wouldn't be smart to explicitly check that the "guaranteeing"
> column is not attisdropped.
Yea, that probably would be smart. I don't think there's an active
problem, because we remove NOT NULL when deleting an attribute, but it
seems good to be doubly sure / explain why that's safe:
/* Remove any NOT NULL constraint the column may have */
attStruct->attnotnull = false;
I'm a bit unsure whether to make it an assert, elog(ERROR) or just not
assume column presence?
Greetings,
Andres Freund