Re: clean up docs for v12 - Mailing list pgsql-hackers

From Tom Lane
Subject Re: clean up docs for v12
Date
Msg-id 18604.1555954037@sss.pgh.pa.us
Whole thread Raw
In response to Re: clean up docs for v12  (Andres Freund <andres@anarazel.de>)
Responses Re: clean up docs for v12
List pgsql-hackers
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.)  I wonder
also if it wouldn't be smart to explicitly check that the "guaranteeing"
column is not attisdropped.

> I think just reformulating that to something like

>     /*
>      * Check if it's guaranteed that all the desired attributes are available
>      * in the tuple (but still possibly NULL), by dint of either the last
>      * to-be-deformed column being NOT NULL, or subsequent ones not accessed
>      * here being NOT NULL.  If that's not guaranteed the tuple headers natt's
>      * has to be checked, and missing attributes potentially have to be
>      * fetched (using slot_getmissingattrs().
>     */

> should make that clearer?

OK by me.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Thoughts on nbtree with logical/varwidth table identifiers, v12on-disk representation
Next
From: Stephen Frost
Date:
Subject: Re: Thoughts on nbtree with logical/varwidth table identifiers, v12on-disk representation