postgresql/src/include/access/tupmacs.h

244 lines
7.2 KiB
C
Raw Normal View History

/*-------------------------------------------------------------------------
*
* tupmacs.h
* Tuple macros used by both index tuples and heap tuples.
*
*
* Portions Copyright (c) 1996-2019, PostgreSQL Global Development Group
* Portions Copyright (c) 1994, Regents of the University of California
*
2010-09-20 22:08:53 +02:00
* src/include/access/tupmacs.h
*
*-------------------------------------------------------------------------
*/
#ifndef TUPMACS_H
#define TUPMACS_H
/*
* check to see if the ATT'th bit of an array of 8-bit bytes is set.
*/
#define att_isnull(ATT, BITS) (!((BITS)[(ATT) >> 3] & (1 << ((ATT) & 0x07))))
/*
* Given a Form_pg_attribute and a pointer into a tuple's data area,
* return the correct value or pointer.
*
* We return a Datum value in all cases. If the attribute has "byval" false,
* we return the same pointer into the tuple data area that we're passed.
* Otherwise, we return the correct number of bytes fetched from the data
* area and extended to Datum form.
*
* On machines where Datum is 8 bytes, we support fetching 8-byte byval
* attributes; otherwise, only 1, 2, and 4-byte values are supported.
*
* Note that T must already be properly aligned for this to work correctly.
*/
#define fetchatt(A,T) fetch_att(T, (A)->attbyval, (A)->attlen)
/*
* Same, but work from byval/len parameters rather than Form_pg_attribute.
*/
#if SIZEOF_DATUM == 8
#define fetch_att(T,attbyval,attlen) \
1998-02-01 06:38:40 +01:00
( \
(attbyval) ? \
1998-02-01 06:38:40 +01:00
( \
(attlen) == (int) sizeof(Datum) ? \
*((Datum *)(T)) \
: \
( \
(attlen) == (int) sizeof(int32) ? \
Int32GetDatum(*((int32 *)(T))) \
: \
1998-02-01 06:38:40 +01:00
( \
(attlen) == (int) sizeof(int16) ? \
Int16GetDatum(*((int16 *)(T))) \
: \
( \
AssertMacro((attlen) == 1), \
CharGetDatum(*((char *)(T))) \
) \
1998-02-01 06:38:40 +01:00
) \
) \
) \
: \
PointerGetDatum((char *) (T)) \
)
2001-03-22 05:01:46 +01:00
#else /* SIZEOF_DATUM != 8 */
#define fetch_att(T,attbyval,attlen) \
( \
(attbyval) ? \
( \
(attlen) == (int) sizeof(int32) ? \
Int32GetDatum(*((int32 *)(T))) \
: \
1998-02-01 06:38:40 +01:00
( \
(attlen) == (int) sizeof(int16) ? \
Int16GetDatum(*((int16 *)(T))) \
1998-02-01 06:38:40 +01:00
: \
( \
AssertMacro((attlen) == 1), \
CharGetDatum(*((char *)(T))) \
) \
1998-02-01 06:38:40 +01:00
) \
) \
1998-02-01 06:38:40 +01:00
: \
PointerGetDatum((char *) (T)) \
1998-02-01 06:38:40 +01:00
)
Phase 2 of pgindent updates. Change pg_bsd_indent to follow upstream rules for placement of comments to the right of code, and remove pgindent hack that caused comments following #endif to not obey the general rule. Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using the published version of pg_bsd_indent, but a hacked-up version that tried to minimize the amount of movement of comments to the right of code. The situation of interest is where such a comment has to be moved to the right of its default placement at column 33 because there's code there. BSD indent has always moved right in units of tab stops in such cases --- but in the previous incarnation, indent was working in 8-space tab stops, while now it knows we use 4-space tabs. So the net result is that in about half the cases, such comments are placed one tab stop left of before. This is better all around: it leaves more room on the line for comment text, and it means that in such cases the comment uniformly starts at the next 4-space tab stop after the code, rather than sometimes one and sometimes two tabs after. Also, ensure that comments following #endif are indented the same as comments following other preprocessor commands such as #else. That inconsistency turns out to have been self-inflicted damage from a poorly-thought-through post-indent "fixup" in pgindent. This patch is much less interesting than the first round of indent changes, but also bulkier, so I thought it best to separate the effects. Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
#endif /* SIZEOF_DATUM == 8 */
/*
* att_align_datum aligns the given offset as needed for a datum of alignment
* requirement attalign and typlen attlen. attdatum is the Datum variable
* we intend to pack into a tuple (it's only accessed if we are dealing with
* a varlena type). Note that this assumes the Datum will be stored as-is;
* callers that are intending to convert non-short varlena datums to short
* format have to account for that themselves.
*/
#define att_align_datum(cur_offset, attalign, attlen, attdatum) \
( \
((attlen) == -1 && VARATT_IS_SHORT(DatumGetPointer(attdatum))) ? \
(uintptr_t) (cur_offset) : \
att_align_nominal(cur_offset, attalign) \
)
/*
* att_align_pointer performs the same calculation as att_align_datum,
* but is used when walking a tuple. attptr is the current actual data
* pointer; when accessing a varlena field we have to "peek" to see if we
* are looking at a pad byte or the first byte of a 1-byte-header datum.
* (A zero byte must be either a pad byte, or the first byte of a correctly
* aligned 4-byte length word; in either case we can align safely. A non-zero
* byte must be either a 1-byte length word, or the first byte of a correctly
* aligned 4-byte length word; in either case we need not align.)
*
* Note: some callers pass a "char *" pointer for cur_offset. This is
* a bit of a hack but should work all right as long as uintptr_t is the
* correct width.
*/
#define att_align_pointer(cur_offset, attalign, attlen, attptr) \
( \
((attlen) == -1 && VARATT_NOT_PAD_BYTE(attptr)) ? \
(uintptr_t) (cur_offset) : \
att_align_nominal(cur_offset, attalign) \
)
/*
* att_align_nominal aligns the given offset as needed for a datum of alignment
* requirement attalign, ignoring any consideration of packed varlena datums.
* There are three main use cases for using this macro directly:
2007-11-15 22:14:46 +01:00
* * we know that the att in question is not varlena (attlen != -1);
* in this case it is cheaper than the above macros and just as good.
* * we need to estimate alignment padding cost abstractly, ie without
* reference to a real tuple. We must assume the worst case that
* all varlenas are aligned.
* * within arrays, we unconditionally align varlenas (XXX this should be
* revisited, probably).
*
* The attalign cases are tested in what is hopefully something like their
* frequency of occurrence.
*/
#define att_align_nominal(cur_offset, attalign) \
( \
((attalign) == 'i') ? INTALIGN(cur_offset) : \
(((attalign) == 'c') ? (uintptr_t) (cur_offset) : \
(((attalign) == 'd') ? DOUBLEALIGN(cur_offset) : \
( \
AssertMacro((attalign) == 's'), \
SHORTALIGN(cur_offset) \
))) \
)
/*
* att_addlength_datum increments the given offset by the space needed for
* the given Datum variable. attdatum is only accessed if we are dealing
* with a variable-length attribute.
*/
#define att_addlength_datum(cur_offset, attlen, attdatum) \
att_addlength_pointer(cur_offset, attlen, DatumGetPointer(attdatum))
/*
* att_addlength_pointer performs the same calculation as att_addlength_datum,
* but is used when walking a tuple --- attptr is the pointer to the field
* within the tuple.
*
* Note: some callers pass a "char *" pointer for cur_offset. This is
* actually perfectly OK, but probably should be cleaned up along with
* the same practice for att_align_pointer.
*/
#define att_addlength_pointer(cur_offset, attlen, attptr) \
( \
((attlen) > 0) ? \
( \
(cur_offset) + (attlen) \
) \
: (((attlen) == -1) ? \
( \
(cur_offset) + VARSIZE_ANY(attptr) \
) \
: \
( \
AssertMacro((attlen) == -2), \
(cur_offset) + (strlen((char *) (attptr)) + 1) \
)) \
)
1999-05-25 18:15:34 +02:00
/*
* store_att_byval is a partial inverse of fetch_att: store a given Datum
* value into a tuple data area at the specified address. However, it only
* handles the byval case, because in typical usage the caller needs to
* distinguish by-val and by-ref cases anyway, and so a do-it-all macro
* wouldn't be convenient.
*/
#if SIZEOF_DATUM == 8
#define store_att_byval(T,newdatum,attlen) \
do { \
switch (attlen) \
{ \
case sizeof(char): \
*(char *) (T) = DatumGetChar(newdatum); \
break; \
case sizeof(int16): \
*(int16 *) (T) = DatumGetInt16(newdatum); \
break; \
case sizeof(int32): \
*(int32 *) (T) = DatumGetInt32(newdatum); \
break; \
case sizeof(Datum): \
*(Datum *) (T) = (newdatum); \
break; \
default: \
2003-07-27 19:10:07 +02:00
elog(ERROR, "unsupported byval length: %d", \
(int) (attlen)); \
break; \
} \
} while (0)
2001-03-22 05:01:46 +01:00
#else /* SIZEOF_DATUM != 8 */
#define store_att_byval(T,newdatum,attlen) \
do { \
switch (attlen) \
{ \
case sizeof(char): \
*(char *) (T) = DatumGetChar(newdatum); \
break; \
case sizeof(int16): \
*(int16 *) (T) = DatumGetInt16(newdatum); \
break; \
case sizeof(int32): \
*(int32 *) (T) = DatumGetInt32(newdatum); \
break; \
default: \
2003-07-27 19:10:07 +02:00
elog(ERROR, "unsupported byval length: %d", \
(int) (attlen)); \
break; \
} \
} while (0)
Phase 2 of pgindent updates. Change pg_bsd_indent to follow upstream rules for placement of comments to the right of code, and remove pgindent hack that caused comments following #endif to not obey the general rule. Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using the published version of pg_bsd_indent, but a hacked-up version that tried to minimize the amount of movement of comments to the right of code. The situation of interest is where such a comment has to be moved to the right of its default placement at column 33 because there's code there. BSD indent has always moved right in units of tab stops in such cases --- but in the previous incarnation, indent was working in 8-space tab stops, while now it knows we use 4-space tabs. So the net result is that in about half the cases, such comments are placed one tab stop left of before. This is better all around: it leaves more room on the line for comment text, and it means that in such cases the comment uniformly starts at the next 4-space tab stop after the code, rather than sometimes one and sometimes two tabs after. Also, ensure that comments following #endif are indented the same as comments following other preprocessor commands such as #else. That inconsistency turns out to have been self-inflicted damage from a poorly-thought-through post-indent "fixup" in pgindent. This patch is much less interesting than the first round of indent changes, but also bulkier, so I thought it best to separate the effects. Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
#endif /* SIZEOF_DATUM == 8 */
#endif