Gregory Stark <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq