"Tom Lane" <tgl@sss.pgh.pa.us> writes:
> I'd be inclined to make the second byte be the length and have
> VARSIZE_1B_E depend on that --- any objection?
On one hand it offends me since it's hard coding an assumption that the size
of a pointer decides what it contains and vice versa. There's nothing saying
we won't have two possible special meanings for a one-byte datum.
And it forecloses any possibility of having a type whose size is at all
variable. I like your idea of using the 4-byte header for variable sized
structures, but what about structures whose size depends on an architecture
detail. We might one day have a pointer which contains a wchar_t or a bigint
and then not have any way to tell whether we have a conflict with some other
pointer structure on some architectures.
On the other hand I suppose you're concerned about the time to do a few
comparisons before knowing which length to skip over? I'm not entirely sure
cycle-counting at that level leads to the correct conclusions. In particular I
think a few checks against constant values followed by a single assignment can
actually be cheaper with speculative execution than having to copy data from
memory and then do subsequent calculations depending on it. I'm not sure we'll
every know though since I doubt it will be measurable.
(I'm also not entirely clear which length to put in, the entire length
including the header or the length just of the pointer. Personally I think I
would prefer just the pointer. I suppose that makes the macro
VARSIZE_EXTERNAL_EXHDR_EXHDR() :/ )
-- Gregory Stark EnterpriseDB http://www.enterprisedb.com