Gregory Stark <stark@enterprisedb.com> writes:
> There's also VARATT_CDATA which I suppose I should rename to VARCDATA. I
> may not even need it once I hit tuptoaster.c since that file works directly
> with the structure members anyways.
> I supposed we also rename VARATT_IS_{COMPRESSED,EXTERNAL,EXTENDED} ?
> Is VAR_IS_* ok or does that sound too generic?
I think the VARATT_xxx names are OK for stuff that is intended to be
private to the TOAST-related code (or at least not intended for
widespread use). Maybe part of the problem is just that postgres.h
fails to document which macros are preferred for widespread use and
which are semi-private.
> For the internal macros for each specific size I have:
> #define VARDATA_4B(PTR) ((PTR)->va_4byte.va_data)
> #define VARDATA_2B(PTR) ((PTR)->va_2byte.va_data)
> #define VARDATA_1B(PTR) ((PTR)->va_1byte.va_data)
I thought we had abandoned the 2-byte-header variant? Maybe you need to
start a separate thread about exactly which of the bit-level proposals
you want to implement. There were quite a few tradeoffs discussed in
the previous thread IIRC.
> Incidentally I profiled htonl against a right shift on my machine (an intel
> 2Ghz core duo). htonl is four times slower but that's 3.2ns versus 0.8ns.
Yeah, but what about machines that have stupider compilers, or maybe
htonl isn't inlined at all? With a shift you pretty much know what
you're getting, with htonl I'm not so sure.
regards, tom lane