<div class="gmail_quote">On Thu, May 21, 2009 at 6:45 PM, Tom Lane <span dir="ltr"><<a
href="mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.pa.us</a>></span>wrote:<br /><blockquote class="gmail_quote"
style="border-left:1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">Sam
Mason<<a href="mailto:sam@samason.me.uk">sam@samason.me.uk</a>> writes:<br /> > On Thu, May 21, 2009 at
12:06:29PM+0400, Dmitry Koterov wrote:<br /> >> ALTER TABLE ... ADD COLUMN ... NULL;<br /> >><br />
>>(nullable without a default value). This is because of NULL bitmap in<br /> >> tuples. And it's greatest
featurefor a developer!<br /><br /> > I don't think this is because of the "NULL bitmap".<br /><br /></div>No, it
isn't. It's because each tuple includes the actual count of<br /> fields it contains (t_natts or
HeapTupleHeaderGetNatts),and the value<br /> extraction routines are coded to assume that references to fields<br />
beyondthat number should yield NULL. So the ALTER can just leave<br /> the existing rows alone --- only when you
updatea row will it change<br /> to include the newly added field(s).<br /></blockquote></div><br />No, I meant that in
caseof the row (1, NULL, NULL, 2, 3, NULL):<br />- the corresponding NULL bitmap is (100110...)<br />- the
correspondingtuple is (1, 2, 3)<br />- t_natts=3 (if I am not wrong here)<br /><br />And in case of the row (5, 6,
NULL,7, 8, 9):<br />- the corresponding NULL bitmap is (110111...)<br /> - the corresponding tuple is (5, 6, 7, 9)<br
/>- t_natts=4<br /><br />So, without a NULL bitmap, we cannot handle this kind of rows at all by t_natts only. And the
NULLbitmap plays very important role in tuple saving, and I meant exactly that point. <br /><br /><br />
