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
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 |