Remove nearly-unused SizeOfIptrData macro.

Past refactorings have removed all but one reference to SizeOfIptrData
(and that one place was in a pretty noncritical spot).  Since nobody's
complained, it seems probable that there are no supported compilers
that don't think sizeof(ItemPointerData) is 6.  If there are, we're
wasting MAXALIGN per heap tuple anyway, so it's rather silly to worry
about whether we can shave space in places like WAL records.

Pavan Deolasee

Discussion: <CABOikdOOawDda4hwLOT6zdA6MFfPLu3Z2YBZkX0JdayNS6JOeQ@mail.gmail.com>

src/backend/executor/nodeTidscan.c

@@ -139,7 +139,7 @@ TidListCreate(TidScanState *tidstate)
 				continue;
 			itemarray = DatumGetArrayTypeP(arraydatum);
 			deconstruct_array(itemarray,
-							  TIDOID, SizeOfIptrData, false, 's',
+							  TIDOID, sizeof(ItemPointerData), false, 's',
 							  &ipdatums, &ipnulls, &ndatums);
 			if (numTids + ndatums > numAllocTids)
 			{

src/include/storage/itemptr.h

@@ -30,9 +30,8 @@
  * structure padding bytes.  The struct is designed to be six bytes long
  * (it contains three int16 fields) but a few compilers will pad it to
  * eight bytes unless coerced.  We apply appropriate persuasion where
- * possible, and to cope with unpersuadable compilers, we try to use
- * "SizeOfIptrData" rather than "sizeof(ItemPointerData)" when computing
- * on-disk sizes.
+ * possible.  If your compiler can't be made to play along, you'll waste
+ * lots of space.
  */
 typedef struct ItemPointerData
 {
@@ -46,9 +45,6 @@ pg_attribute_aligned(2)
 #endif
 ItemPointerData;
 
-#define SizeOfIptrData	\
-	(offsetof(ItemPointerData, ip_posid) + sizeof(OffsetNumber))
-
 typedef ItemPointerData *ItemPointer;
 
 /* ----------------