"Tom Lane" <tgl@sss.pgh.pa.us> writes:
> Plus you can't do it without multiple evaluation of the macro argument,
> which is something I'd really prefer we not introduce into such a
> widely-used macro.
I don't see any way to do VARSIZE without multiply evaluating its argument.
It's got to mask out the relevant bits then take the appropriate number of
bytes and shift the appropriate number of bits to the right.
If we wanted to require GCC we could use temporary variables in macros. Or we
could use a global variable and declare that you can't use VARSIZE inside the
argument to VARSIZE. (Actually I can't construct a scenario where it would
break, perhaps it's safe.)
But I just did a find-grep and the most complicated expression I can find is
VARATT_SIZE(DatumGetPointer(values[i])). And that's in code I think I'll have
to touch anyways. I can't find any instances of anything that would be
dangerous or noticeably inefficient.
It would be pretty strange code that wanted to know the size of a datum but
didn't care enough about the actual contents of the datum to store it in a
temporary variable. The only circumstances I could see it happening is if
someone wrote code like:
len = VARSIZE(datum = DirectFunctionCall())
There are no instances that I can find of that form that I can find.
> The only argument in favor is to save a couple bytes of alignment padding,
> but since this is only going to happen for wide data values, the
> significance of that is minimal.
Yeah I realized the same thing earlier. At least in the case of four-byte
headers padding is logical on all fronts since nul bytes will have the right
bitpattern. And it's a big cpu win on four-byte headers since it affects
reading non-compressed varlenas being passed around in the executor.
I'm not sure the same logic holds for two-byte headers. They're a) not so
expensive in the first place, b) not so large in the first place and c) would
require padding with a special pad byte.
-- Gregory Stark EnterpriseDB http://www.enterprisedb.com
