Re: att_isnull - Mailing list pgsql-hackers

From Tom Lane
Subject Re: att_isnull
Date
Msg-id 25196.1557499566@sss.pgh.pa.us
Whole thread Raw
In response to Re: att_isnull  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: att_isnull  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> Yeah, I've noticed this inconsistency too.  I doubt we want to change
> the macro definition or its name, but +1 for expanding the comment.
> Your proposed wording seems sufficient.

+1

>> There is some kind of broader confusion here, I think, because we
>> refer in many places to the "null bitmap" but it's actually not a
>> bitmap of which attributes are null but rather of which attributes are
>> not null.  That is confusing in and of itself, and it's also not very
>> intuitive that it uses exactly the opposite convention from what we do
>> with datum/isnull arrays.

> I remember being bit by this inconsistency while fixing data corruption
> problems, but I'm not sure what, if anything, should we do about it.
> Maybe there's a perfect spot where to add some further documentation
> about it (a code comment somewhere?) but I don't know where would that
> be.

It is documented in the "Database Physical Storage" part of the docs,
but no particular emphasis is laid on the 1-vs-0 convention.  Maybe
a few more words there are worthwhile?

            regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Bug in reindexdb's error reporting
Next
From: Tom Lane
Date:
Subject: Re: Unexpected "shared memory block is still in use"