Re: clean up docs for v12

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>, Michael Paquier <michael@paquier.xyz>, Justin Pryzby <pryzby@telsasoft.com>, pgsql-hackers@postgresql.org
Date: 2019-04-22T17:27:17Z
Lists: 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



Commits

  1. Improve code inferring length of bitmap for JITed tuple deforming.

  2. Fix more typos and inconsistencies in documentation

  3. Fix collection of typos and grammar mistakes in docs and comments

  4. Clean up some documentation for log_statement_sample_rate