On 11/10/06, Heikki Linnakangas <heikki@enterprisedb.com> wrote: Tom Lane wrote:
> (Actually, the assumption that you can throw an additional back-pointer
> into overflow tuple headers is the worst feature of this proposal in
> that regard --- it's really not that easy to support multiple header
> formats.)
Well, we already have a variable length null bitmap in the header. It
seems quite straightforward to me to add the new field before the null
bitmap. It certainly requires some changes, in particular to places that
access the null bitmap, but it's not an insurmountable effort. Or am I
missing some less obvious consequences?
We have added the overflow header (which right now contains a single entry i.e.
the back pointer) on the very similar lines to optional Oid field in the tuple header.
A flag (the last free in the t_infomask) is used to check if there is an additional
overflow header and if so t_hoff is adjusted appropriately.
So in the current prototype, the overflow header is after the null bitmap
and before the Oid, if it exists.
Regards,
Pavan