Re: att_isnull

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: att_isnull
Date: 2019-05-10 14:46:06
Message-ID: 25196.1557499566@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera <alvherre(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-05-10 14:55:41 Re: Unexpected "shared memory block is still in use"
Previous Message Tom Lane 2019-05-10 14:43:50 Re: Bug in reindexdb's error reporting