pgindent run for release 9.3

This is the first run of the Perl-based pgindent script.  Also update
pgindent instructions.

5 files changed, 21 insertions, 21 deletions

diff --git a/src/backend/optimizer/path/allpaths.c b/src/backend/optimizer/path/allpaths.c
index 105718ff371..742177f4570 100644
--- a/src/backend/optimizer/path/allpaths.c
+++ b/src/backend/optimizer/path/allpaths.c
@@ -721,7 +721,7 @@ set_append_rel_pathlist(PlannerInfo *root, RelOptInfo *rel,
 		 */
 		if (childrel->cheapest_total_path->param_info == NULL)
 			subpaths = accumulate_append_subpath(subpaths,
-											 childrel->cheapest_total_path);
+											  childrel->cheapest_total_path);
 		else
 			subpaths_valid = false;
 
diff --git a/src/backend/optimizer/path/costsize.c b/src/backend/optimizer/path/costsize.c
index 8d2490208d4..3507f18007e 100644
--- a/src/backend/optimizer/path/costsize.c
+++ b/src/backend/optimizer/path/costsize.c
@@ -69,7 +69,7 @@
 #include "postgres.h"
 
 #ifdef _MSC_VER
-#include <float.h> /* for _isnan */
+#include <float.h>				/* for _isnan */
 #endif
 #include <math.h>
 
@@ -3745,7 +3745,7 @@ set_subquery_size_estimates(PlannerInfo *root, RelOptInfo *rel)
 		 * The subquery could be an expansion of a view that's had columns
 		 * added to it since the current query was parsed, so that there are
 		 * non-junk tlist columns in it that don't correspond to any column
-		 * visible at our query level.  Ignore such columns.
+		 * visible at our query level.	Ignore such columns.
 		 */
 		if (te->resno < rel->min_attr || te->resno > rel->max_attr)
 			continue;
diff --git a/src/backend/optimizer/path/equivclass.c b/src/backend/optimizer/path/equivclass.c
index cbb4f5cd956..711b161c0d1 100644
--- a/src/backend/optimizer/path/equivclass.c
+++ b/src/backend/optimizer/path/equivclass.c
@@ -294,7 +294,7 @@ process_equivalence(PlannerInfo *root, RestrictInfo *restrictinfo,
 
 		/*
 		 * We add ec2's items to ec1, then set ec2's ec_merged link to point
-		 * to ec1 and remove ec2 from the eq_classes list.  We cannot simply
+		 * to ec1 and remove ec2 from the eq_classes list.	We cannot simply
 		 * delete ec2 because that could leave dangling pointers in existing
 		 * PathKeys.  We leave it behind with a link so that the merged EC can
 		 * be found.
@@ -2083,9 +2083,9 @@ generate_implied_equalities_for_column(PlannerInfo *root,
 			continue;
 
 		/*
-		 * Scan members, looking for a match to the target column.  Note
-		 * that child EC members are considered, but only when they belong to
-		 * the target relation.  (Unlike regular members, the same expression
+		 * Scan members, looking for a match to the target column.	Note that
+		 * child EC members are considered, but only when they belong to the
+		 * target relation.  (Unlike regular members, the same expression
 		 * could be a child member of more than one EC.  Therefore, it's
 		 * potentially order-dependent which EC a child relation's target
 		 * column gets matched to.	This is annoying but it only happens in
diff --git a/src/backend/optimizer/path/indxpath.c b/src/backend/optimizer/path/indxpath.c
index d74603983bc..65eb344cde4 100644
--- a/src/backend/optimizer/path/indxpath.c
+++ b/src/backend/optimizer/path/indxpath.c
@@ -250,7 +250,7 @@ create_index_paths(PlannerInfo *root, RelOptInfo *rel)
 	 * If there are any rels that have LATERAL references to this one, we
 	 * cannot use join quals referencing them as index quals for this one,
 	 * since such rels would have to be on the inside not the outside of a
-	 * nestloop join relative to this one.  Create a Relids set listing all
+	 * nestloop join relative to this one.	Create a Relids set listing all
 	 * such rels, for use in checks of potential join clauses.
 	 */
 	lateral_referencers = NULL;
@@ -482,7 +482,7 @@ consider_index_join_clauses(PlannerInfo *root, RelOptInfo *rel,
 	 *
 	 * For simplicity in selecting relevant clauses, we represent each set of
 	 * outer rels as a maximum set of clause_relids --- that is, the indexed
-	 * relation itself is also included in the relids set.  considered_relids
+	 * relation itself is also included in the relids set.	considered_relids
 	 * lists all relids sets we've already tried.
 	 */
 	for (indexcol = 0; indexcol < index->ncolumns; indexcol++)
@@ -557,7 +557,7 @@ consider_index_join_outer_rels(PlannerInfo *root, RelOptInfo *rel,
 		 */
 		foreach(lc2, *considered_relids)
 		{
-			Relids	oldrelids = (Relids) lfirst(lc2);
+			Relids		oldrelids = (Relids) lfirst(lc2);
 
 			/*
 			 * If either is a subset of the other, no new set is possible.
@@ -571,7 +571,7 @@ consider_index_join_outer_rels(PlannerInfo *root, RelOptInfo *rel,
 			/*
 			 * If this clause was derived from an equivalence class, the
 			 * clause list may contain other clauses derived from the same
-			 * eclass.  We should not consider that combining this clause with
+			 * eclass.	We should not consider that combining this clause with
 			 * one of those clauses generates a usefully different
 			 * parameterization; so skip if any clause derived from the same
 			 * eclass would already have been included when using oldrelids.
@@ -654,9 +654,9 @@ get_join_index_paths(PlannerInfo *root, RelOptInfo *rel,
 		}
 
 		/*
-		 * Add applicable eclass join clauses.  The clauses generated for each
+		 * Add applicable eclass join clauses.	The clauses generated for each
 		 * column are redundant (cf generate_implied_equalities_for_column),
-		 * so we need at most one.  This is the only exception to the general
+		 * so we need at most one.	This is the only exception to the general
 		 * rule of using all available index clauses.
 		 */
 		foreach(lc, eclauseset->indexclauses[indexcol])
@@ -2630,8 +2630,8 @@ check_partial_indexes(PlannerInfo *root, RelOptInfo *rel)
 		return;
 
 	/*
-	 * Construct a list of clauses that we can assume true for the purpose
-	 * of proving the index(es) usable.  Restriction clauses for the rel are
+	 * Construct a list of clauses that we can assume true for the purpose of
+	 * proving the index(es) usable.  Restriction clauses for the rel are
 	 * always usable, and so are any join clauses that are "movable to" this
 	 * rel.  Also, we can consider any EC-derivable join clauses (which must
 	 * be "movable to" this rel, by definition).
@@ -2653,8 +2653,8 @@ check_partial_indexes(PlannerInfo *root, RelOptInfo *rel)
 	/*
 	 * Add on any equivalence-derivable join clauses.  Computing the correct
 	 * relid sets for generate_join_implied_equalities is slightly tricky
-	 * because the rel could be a child rel rather than a true baserel, and
-	 * in that case we must remove its parent's relid from all_baserels.
+	 * because the rel could be a child rel rather than a true baserel, and in
+	 * that case we must remove its parent's relid from all_baserels.
 	 */
 	if (rel->reloptkind == RELOPT_OTHER_MEMBER_REL)
 	{
@@ -2671,8 +2671,8 @@ check_partial_indexes(PlannerInfo *root, RelOptInfo *rel)
 		clauselist =
 			list_concat(clauselist,
 						generate_join_implied_equalities(root,
-														 bms_union(rel->relids,
-																   otherrels),
+													   bms_union(rel->relids,
+																 otherrels),
 														 otherrels,
 														 rel));
 
diff --git a/src/backend/optimizer/path/joinpath.c b/src/backend/optimizer/path/joinpath.c
index e1d6b3e2234..d6050a616c7 100644
--- a/src/backend/optimizer/path/joinpath.c
+++ b/src/backend/optimizer/path/joinpath.c
@@ -154,7 +154,7 @@ add_paths_to_joinrel(PlannerInfo *root,
 	 * However, when a LATERAL subquery is involved, we have to be a bit
 	 * laxer, because there will simply not be any paths for the joinrel that
 	 * aren't parameterized by whatever the subquery is parameterized by,
-	 * unless its parameterization is resolved within the joinrel.  Hence, add
+	 * unless its parameterization is resolved within the joinrel.	Hence, add
 	 * to param_source_rels anything that is laterally referenced in either
 	 * input and is not in the join already.
 	 */
@@ -507,7 +507,7 @@ sort_inner_and_outer(PlannerInfo *root,
 	 * sort.
 	 *
 	 * This function intentionally does not consider parameterized input
-	 * paths, except when the cheapest-total is parameterized.  If we did so,
+	 * paths, except when the cheapest-total is parameterized.	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