4 files changed, 10 insertions, 10 deletions
diff --git a/src/include/executor/executor.h b/src/include/executor/executor.h
index bdd499bea66..b834282287d 100644
--- a/src/include/executor/executor.h
+++ b/src/include/executor/executor.h
@@ -36,7 +36,7 @@
  * REWIND indicates that the plan node should try to efficiently support
  * rescans without parameter changes.  (Nodes must support ExecReScan calls
  * in any case, but if this flag was not given, they are at liberty to do it
- * through complete recalculation.	Note that a parameter change forces a
+ * through complete recalculation.  Note that a parameter change forces a
  * full recalculation in any case.)
  *
  * BACKWARD indicates that the plan node must respect the es_direction flag.
diff --git a/src/include/executor/hashjoin.h b/src/include/executor/hashjoin.h
index 0c6e06f8ff5..24aa8ad096a 100644
--- a/src/include/executor/hashjoin.h
+++ b/src/include/executor/hashjoin.h
@@ -42,7 +42,7 @@
  * If nbatch > 1 then tuples that don't belong in first batch get saved
  * into inner-batch temp files. The same statements apply for the
  * first scan of the outer relation, except we write tuples to outer-batch
- * temp files.	After finishing the first scan, we do the following for
+ * temp files.  After finishing the first scan, we do the following for
  * each remaining batch:
  *	1. Read tuples from inner batch file, load into hash buckets.
  *	2. Read tuples from outer batch file, match to hash buckets and output.
@@ -133,7 +133,7 @@ typedef struct HashJoinTableData
 
 	/*
 	 * These arrays are allocated for the life of the hash join, but only if
-	 * nbatch > 1.	A file is opened only when we first write a tuple into it
+	 * nbatch > 1.  A file is opened only when we first write a tuple into it
 	 * (otherwise its pointer remains NULL).  Note that the zero'th array
 	 * elements never get used, since we will process rather than dump out any
 	 * tuples of batch zero.
diff --git a/src/include/executor/spi_priv.h b/src/include/executor/spi_priv.h
index 5865f532802..1c66263432d 100644
--- a/src/include/executor/spi_priv.h
+++ b/src/include/executor/spi_priv.h
@@ -43,7 +43,7 @@ typedef struct
  * For a saved plan, the _SPI_plan struct and the argument type array are in
  * the plancxt (which can be really small).  All the other subsidiary state
  * is in plancache entries identified by plancache_list (note: the list cells
- * themselves are in plancxt).	We rely on plancache.c to keep the cache
+ * themselves are in plancxt).  We rely on plancache.c to keep the cache
  * entries up-to-date as needed.  The plancxt is a child of CacheMemoryContext
  * since it should persist until explicitly destroyed.
  *
diff --git a/src/include/executor/tuptable.h b/src/include/executor/tuptable.h
index f774f2d0ab6..8b7d336a15a 100644
--- a/src/include/executor/tuptable.h
+++ b/src/include/executor/tuptable.h
@@ -34,7 +34,7 @@
  *
  * A "minimal" tuple is handled similarly to a palloc'd regular tuple.
  * At present, minimal tuples never are stored in buffers, so there is no
- * parallel to case 1.	Note that a minimal tuple has no "system columns".
+ * parallel to case 1.  Note that a minimal tuple has no "system columns".
  * (Actually, it could have an OID, but we have no need to access the OID.)
  *
  * A "virtual" tuple is an optimization used to minimize physical data
@@ -44,7 +44,7 @@
  * a lower plan node's output TupleTableSlot, or to a function result
  * constructed in a plan node's per-tuple econtext.  It is the responsibility
  * of the generating plan node to be sure these resources are not released
- * for as long as the virtual tuple needs to be valid.	We only use virtual
+ * for as long as the virtual tuple needs to be valid.  We only use virtual
  * tuples in the result slots of plan nodes --- tuples to be copied anywhere
  * else need to be "materialized" into physical tuples.  Note also that a
  * virtual tuple does not have any "system columns".
@@ -58,11 +58,11 @@
  * payloads when this is the case.
  *
  * The Datum/isnull arrays of a TupleTableSlot serve double duty.  When the
- * slot contains a virtual tuple, they are the authoritative data.	When the
+ * slot contains a virtual tuple, they are the authoritative data.  When the
  * slot contains a physical tuple, the arrays contain data extracted from
  * the tuple.  (In this state, any pass-by-reference Datums point into
  * the physical tuple.)  The extracted information is built "lazily",
- * ie, only as needed.	This serves to avoid repeated extraction of data
+ * ie, only as needed.  This serves to avoid repeated extraction of data
  * from the physical tuple.
  *
  * A TupleTableSlot can also be "empty", holding no valid data.  This is
@@ -89,7 +89,7 @@
  * buffer page.)
  *
  * tts_nvalid indicates the number of valid columns in the tts_values/isnull
- * arrays.	When the slot is holding a "virtual" tuple this must be equal
+ * arrays.  When the slot is holding a "virtual" tuple this must be equal
  * to the descriptor's natts.  When the slot is holding a physical tuple
  * this is equal to the number of columns we have extracted (we always
  * extract columns from left to right, so there are no holes).
@@ -103,7 +103,7 @@
  * has only a minimal and not also a regular physical tuple, then tts_tuple
  * points at tts_minhdr and the fields of that struct are set correctly
  * for access to the minimal tuple; in particular, tts_minhdr.t_data points
- * MINIMAL_TUPLE_OFFSET bytes before tts_mintuple.	This allows column
+ * MINIMAL_TUPLE_OFFSET bytes before tts_mintuple.  This allows column
  * extraction to treat the case identically to regular physical tuples.
  *
  * tts_slow/tts_off are saved state for slot_deform_tuple, and should not