Remove tabs after spaces in C comments

This was not changed in HEAD, but will be done later as part of a
pgindent run.  Future pgindent runs will also do this.

Report by Tom Lane

Backpatch through all supported branches, but not HEAD

1 files changed, 12 insertions, 12 deletions

diff --git a/src/backend/optimizer/path/joinpath.c b/src/backend/optimizer/path/joinpath.c
index 65f86194e15..42ec5588cd1 100644
--- a/src/backend/optimizer/path/joinpath.c
+++ b/src/backend/optimizer/path/joinpath.c
@@ -103,7 +103,7 @@ add_paths_to_joinrel(PlannerInfo *root,
 
 	/*
 	 * If it's SEMI or ANTI join, compute correction factors for cost
-	 * estimation.	These will be the same for all paths.
+	 * estimation.  These will be the same for all paths.
 	 */
 	if (jointype == JOIN_SEMI || jointype == JOIN_ANTI)
 		compute_semi_anti_join_factors(root, outerrel, innerrel,
@@ -118,7 +118,7 @@ add_paths_to_joinrel(PlannerInfo *root,
 	 * to the parameter source rel instead of joining to the other input rel.
 	 * This restriction reduces the number of parameterized paths we have to
 	 * deal with at higher join levels, without compromising the quality of
-	 * the resulting plan.	We express the restriction as a Relids set that
+	 * the resulting plan.  We express the restriction as a Relids set that
 	 * must overlap the parameterization of any proposed join path.
 	 */
 	foreach(lc, root->join_info_list)
@@ -149,7 +149,7 @@ add_paths_to_joinrel(PlannerInfo *root,
 
 	/*
 	 * 1. Consider mergejoin paths where both relations must be explicitly
-	 * sorted.	Skip this if we can't mergejoin.
+	 * sorted.  Skip this if we can't mergejoin.
 	 */
 	if (mergejoin_allowed)
 		sort_inner_and_outer(root, joinrel, outerrel, innerrel,
@@ -172,7 +172,7 @@ add_paths_to_joinrel(PlannerInfo *root,
 
 	/*
 	 * 3. Consider paths where the inner relation need not be explicitly
-	 * sorted.	This includes mergejoins only (nestloops were already built in
+	 * sorted.  This includes mergejoins only (nestloops were already built in
 	 * match_unsorted_outer).
 	 *
 	 * Diked out as redundant 2/13/2000 -- tgl.  There isn't any really
@@ -423,7 +423,7 @@ try_hashjoin_path(PlannerInfo *root,
  * We already know that the clause is a binary opclause referencing only the
  * rels in the current join.  The point here is to check whether it has the
  * form "outerrel_expr op innerrel_expr" or "innerrel_expr op outerrel_expr",
- * rather than mixing outer and inner vars on either side.	If it matches,
+ * rather than mixing outer and inner vars on either side.  If it matches,
  * we set the transient flag outer_is_left to identify which side is which.
  */
 static inline bool
@@ -487,7 +487,7 @@ sort_inner_and_outer(PlannerInfo *root,
 	 *
 	 * This function intentionally does not consider parameterized input paths
 	 * (implicit in the fact that it only looks at cheapest_total_path, which
-	 * is always unparameterized).	If we did so, we'd have a combinatorial
+	 * is always unparameterized).  If we did so, we'd have a combinatorial
 	 * explosion of mergejoin paths of dubious value.  This interacts with
 	 * decisions elsewhere that also discriminate against mergejoins with
 	 * parameterized inputs; see comments in src/backend/optimizer/README.
@@ -521,7 +521,7 @@ sort_inner_and_outer(PlannerInfo *root,
 	 *
 	 * Actually, it's not quite true that every mergeclause ordering will
 	 * generate a different path order, because some of the clauses may be
-	 * partially redundant (refer to the same EquivalenceClasses).	Therefore,
+	 * partially redundant (refer to the same EquivalenceClasses).  Therefore,
 	 * what we do is convert the mergeclause list to a list of canonical
 	 * pathkeys, and then consider different orderings of the pathkeys.
 	 *
@@ -614,7 +614,7 @@ sort_inner_and_outer(PlannerInfo *root,
  * cheapest-total inner-indexscan path (if any), and one on the
  * cheapest-startup inner-indexscan path (if different).
  *
- * We also consider mergejoins if mergejoin clauses are available.	We have
+ * We also consider mergejoins if mergejoin clauses are available.  We have
  * two ways to generate the inner path for a mergejoin: sort the cheapest
  * inner path, or use an inner path that is already suitably ordered for the
  * merge.  If we have several mergeclauses, it could be that there is no inner
@@ -733,8 +733,8 @@ match_unsorted_outer(PlannerInfo *root,
 
 		/*
 		 * If we need to unique-ify the outer path, it's pointless to consider
-		 * any but the cheapest outer.	(XXX we don't consider parameterized
-		 * outers, nor inners, for unique-ified cases.	Should we?)
+		 * any but the cheapest outer.  (XXX we don't consider parameterized
+		 * outers, nor inners, for unique-ified cases.  Should we?)
 		 */
 		if (save_jointype == JOIN_UNIQUE_OUTER)
 		{
@@ -774,7 +774,7 @@ match_unsorted_outer(PlannerInfo *root,
 		{
 			/*
 			 * Consider nestloop joins using this outer path and various
-			 * available paths for the inner relation.	We consider the
+			 * available paths for the inner relation.  We consider the
 			 * cheapest-total paths for each available parameterization of the
 			 * inner relation, including the unparameterized case.
 			 */
@@ -922,7 +922,7 @@ match_unsorted_outer(PlannerInfo *root,
 
 			/*
 			 * Look for an inner path ordered well enough for the first
-			 * 'sortkeycnt' innersortkeys.	NB: trialsortkeys list is modified
+			 * 'sortkeycnt' innersortkeys.  NB: trialsortkeys list is modified
 			 * destructively, which is why we made a copy...
 			 */
 			trialsortkeys = list_truncate(trialsortkeys, sortkeycnt);