diff options
Diffstat (limited to 'src/include/access/htup_details.h')
| -rw-r--r-- | src/include/access/htup_details.h | 16 |
1 files changed, 8 insertions, 8 deletions
diff --git a/src/include/access/htup_details.h b/src/include/access/htup_details.h index 039d4b4cd94..294d21bd180 100644 --- a/src/include/access/htup_details.h +++ b/src/include/access/htup_details.h @@ -70,7 +70,7 @@ * * We store five "virtual" fields Xmin, Cmin, Xmax, Cmax, and Xvac in three * physical fields. Xmin and Xmax are always really stored, but Cmin, Cmax - * and Xvac share a field. This works because we know that Cmin and Cmax + * and Xvac share a field. This works because we know that Cmin and Cmax * are only interesting for the lifetime of the inserting and deleting * transaction respectively. If a tuple is inserted and deleted in the same * transaction, we store a "combo" command id that can be mapped to the real @@ -82,7 +82,7 @@ * ie, an insert-in-progress or delete-in-progress tuple.) * * A word about t_ctid: whenever a new tuple is stored on disk, its t_ctid - * is initialized with its own TID (location). If the tuple is ever updated, + * is initialized with its own TID (location). If the tuple is ever updated, * its t_ctid is changed to point to the replacement version of the tuple. * Thus, a tuple is the latest version of its row iff XMAX is invalid or * t_ctid points to itself (in which case, if XMAX is valid, the tuple is @@ -97,10 +97,10 @@ * check fails, one may assume that there is no live descendant version. * * Following the fixed header fields, the nulls bitmap is stored (beginning - * at t_bits). The bitmap is *not* stored if t_infomask shows that there + * at t_bits). The bitmap is *not* stored if t_infomask shows that there * are no nulls in the tuple. If an OID field is present (as indicated by * t_infomask), then it is stored just before the user data, which begins at - * the offset shown by t_hoff. Note that t_hoff must be a multiple of + * the offset shown by t_hoff. Note that t_hoff must be a multiple of * MAXALIGN. */ @@ -242,7 +242,7 @@ struct HeapTupleHeaderData /* * HeapTupleHeader accessor macros * - * Note: beware of multiple evaluations of "tup" argument. But the Set + * Note: beware of multiple evaluations of "tup" argument. But the Set * macros evaluate their other argument only once. */ @@ -528,7 +528,7 @@ do { \ * MinimalTuple is an alternative representation that is used for transient * tuples inside the executor, in places where transaction status information * is not required, the tuple rowtype is known, and shaving off a few bytes - * is worthwhile because we need to store many tuples. The representation + * is worthwhile because we need to store many tuples. The representation * is chosen so that tuple access routines can work with either full or * minimal tuples via a HeapTupleData pointer structure. The access routines * see no difference, except that they must not access the transaction status @@ -552,7 +552,7 @@ do { \ * the MINIMAL_TUPLE_OFFSET distance. t_len does not include that, however. * * MINIMAL_TUPLE_DATA_OFFSET is the offset to the first useful (non-pad) data - * other than the length word. tuplesort.c and tuplestore.c use this to avoid + * other than the length word. tuplesort.c and tuplestore.c use this to avoid * writing the padding to disk. */ #define MINIMAL_TUPLE_OFFSET \ @@ -698,7 +698,7 @@ extern Datum fastgetattr(HeapTuple tup, int attnum, TupleDesc tupleDesc, * and set *isnull == true. Otherwise, we set *isnull == false. * * <tup> is the pointer to the heap tuple. <attnum> is the attribute - * number of the column (field) caller wants. <tupleDesc> is a + * number of the column (field) caller wants. <tupleDesc> is a * pointer to the structure describing the row and all its fields. * ---------------- */ |