| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
|---|---|
| To: | "Michael Richards" <miker(at)interchange(dot)ca> | 
| Cc: | "Hannu Krosing" <hannu(at)tm(dot)ee>, pgsql-hackers(at)postgresql(dot)org | 
| Subject: | Re: Tuple data | 
| Date: | 2000-12-17 02:23:23 | 
| Message-ID: | 19562.977019803@sss.pgh.pa.us | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
"Michael Richards" <miker(at)interchange(dot)ca> writes:
> Sometimes the t_hoff value in the tuple header is 32 which seems to indicate
> no NULL bitmap.
There's no null bitmap unless the HASNULLS infomask bit is set.
> This really makes me wonder what happens when you ALTER
> TABLE ADD COLUMN on a table since it doesn't seem to take more than O(1)
> time. Perhaps it is assumed if the attribute count is less than the actual
> number of attributes then the last ones are NULL and no NULL map is
> required.
ALTER ADD COLUMN doesn't touch any tuples, and you're right that it's
critically dependent on heap_getattr returning NULL when an attribute
beyond the number of attributes actually present in a tuple is accessed.
That's a fragile and unclean implementation IMHO --- see past traffic
on this list.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2000-12-17 02:46:50 | Re: [HACKERS] 7.1 features list | 
| Previous Message | Stephan Szabo | 2000-12-17 02:05:50 | Re: locking bug? |