On Tue, 16 Jul 2002 12:23:01 -0400, Tom Lane <tgl@sss.pgh.pa.us>
wrote:
>I've been thinking that it's really not a good idea to make the OID
>field optional without any indication in the tuple header whether it
>is present. In particular, this will make life difficult for tools
>like pg_filedump that try to display tuple headers without any outside
>information. I think it'd be a good idea to expend a bit in t_infomask
>to show whether an OID field is allocated or not.
If we want, we can get along without using a bit. On machines with 4
byte alignment the presence of an oid can be deduced from the tuple
header length, t_hoff. The "Optional Oid" patch defines a macro
HeapTupleHeaderExpectedLen in htup.h. This macro is currently only
used for debugging; we could expose this or a similar macro or
function to tools.
A little problem arises with 8 byte alignment: due to padding tuple
headers with or without oid might have the same length. If padding
bytes are properly set to 0, those tools would display "Invalid Oid"
instead of "No Oid".
>We currently have two free bits in t_infomask, which is starting to get
>a bit tight, but offhand I do not see anything else coming down the pike
>that would need another bit. Also, we could consider expanding
>t_infomask to three bytes if we had to.
... and if we are really miserly, we use those two or three bits in
t_hoff, which are always 0 because t_hoff = MAXALIGN(...).
I'm not strongly biased towards either direction. If we end up using
a bit in t_infomask, I'll change the announcement to "This patch
reduces per tuple overhead by 31 bits ..."
I've finished the patch yesterday and have posted it to -patches this
morning. Please have a look at it.
ServusManfred