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, 21 insertions, 21 deletions

diff --git a/src/backend/rewrite/rewriteHandler.c b/src/backend/rewrite/rewriteHandler.c
index 1ac048d78e5..6a31c62331e 100644
--- a/src/backend/rewrite/rewriteHandler.c
+++ b/src/backend/rewrite/rewriteHandler.c
@@ -208,7 +208,7 @@ AcquireRewriteLocks(Query *parsetree,
 						/*
 						 * The elements of an alias list have to refer to
 						 * earlier RTEs of the same rtable, because that's the
-						 * order the planner builds things in.	So we already
+						 * order the planner builds things in.  So we already
 						 * processed the referenced RTE, and so it's safe to
 						 * use get_rte_attribute_is_dropped on it. (This might
 						 * not hold after rewriting or planning, but it's OK
@@ -370,7 +370,7 @@ rewriteRuleAction(Query *parsetree,
 	/*
 	 * Generate expanded rtable consisting of main parsetree's rtable plus
 	 * rule action's rtable; this becomes the complete rtable for the rule
-	 * action.	Some of the entries may be unused after we finish rewriting,
+	 * action.  Some of the entries may be unused after we finish rewriting,
 	 * but we leave them all in place for two reasons:
 	 *
 	 * We'd have a much harder job to adjust the query's varnos if we
@@ -436,7 +436,7 @@ rewriteRuleAction(Query *parsetree,
 	 * that if the rule action refers to OLD, its jointree will add a
 	 * reference to rt_index.  If the rule action doesn't refer to OLD, but
 	 * either the rule_qual or the user query quals do, then we need to keep
-	 * the original rtindex in the jointree to provide data for the quals.	We
+	 * the original rtindex in the jointree to provide data for the quals.  We
 	 * don't want the original rtindex to be joined twice, however, so avoid
 	 * keeping it if the rule action mentions it.
 	 *
@@ -458,7 +458,7 @@ rewriteRuleAction(Query *parsetree,
 		{
 			/*
 			 * If sub_action is a setop, manipulating its jointree will do no
-			 * good at all, because the jointree is dummy.	(Perhaps someday
+			 * good at all, because the jointree is dummy.  (Perhaps someday
 			 * we could push the joining and quals down to the member
 			 * statements of the setop?)
 			 */
@@ -661,7 +661,7 @@ adjustJoinTreeList(Query *parsetree, bool removert, int rt_index)
  * then junk fields (these in no particular order).
  *
  * We must do items 1,2,3 before firing rewrite rules, else rewritten
- * references to NEW.foo will produce wrong or incomplete results.	Item 4
+ * references to NEW.foo will produce wrong or incomplete results.  Item 4
  * is not needed for rewriting, but will be needed by the planner, and we
  * can do it essentially for free while handling the other items.
  *
@@ -868,7 +868,7 @@ process_matched_tle(TargetEntry *src_tle,
 	}
 
 	/*----------
-	 * Multiple assignments to same attribute.	Allow only if all are
+	 * Multiple assignments to same attribute.  Allow only if all are
 	 * FieldStore or ArrayRef assignment operations.  This is a bit
 	 * tricky because what we may actually be looking at is a nest of
 	 * such nodes; consider
@@ -886,7 +886,7 @@ process_matched_tle(TargetEntry *src_tle,
 	 * assignments appear to occur left-to-right.
 	 *
 	 * For FieldStore, instead of nesting we can generate a single
-	 * FieldStore with multiple target fields.	We must nest when
+	 * FieldStore with multiple target fields.  We must nest when
 	 * ArrayRefs are involved though.
 	 *----------
 	 */
@@ -1178,7 +1178,7 @@ rewriteValuesRTE(RangeTblEntry *rte, Relation target_relation, List *attrnos)
  * rewriteTargetListUD - rewrite UPDATE/DELETE targetlist as needed
  *
  * This function adds a "junk" TLE that is needed to allow the executor to
- * find the original row for the update or delete.	When the target relation
+ * find the original row for the update or delete.  When the target relation
  * is a regular table, the junk TLE emits the ctid attribute of the original
  * row.  When the target relation is a view, there is no ctid, so we instead
  * emit a whole-row Var that will contain the "old" values of the view row.
@@ -1351,9 +1351,9 @@ ApplyRetrieveRule(Query *parsetree,
 		 * fine as the result relation.
 		 *
 		 * For UPDATE/DELETE, we need to expand the view so as to have source
-		 * data for the operation.	But we also need an unmodified RTE to
+		 * data for the operation.  But we also need an unmodified RTE to
 		 * serve as the target.  So, copy the RTE and add the copy to the
-		 * rangetable.	Note that the copy does not get added to the jointree.
+		 * rangetable.  Note that the copy does not get added to the jointree.
 		 * Also note that there's a hack in fireRIRrules to avoid calling this
 		 * function again when it arrives at the copied RTE.
 		 */
@@ -1525,7 +1525,7 @@ markQueryForLocking(Query *qry, Node *jtnode,
  *	in the given tree.
  *
  * NOTE: although this has the form of a walker, we cheat and modify the
- * SubLink nodes in-place.	It is caller's responsibility to ensure that
+ * SubLink nodes in-place.  It is caller's responsibility to ensure that
  * no unwanted side-effects occur!
  *
  * This is unlike most of the other routines that recurse into subselects,
@@ -1730,7 +1730,7 @@ fireRIRrules(Query *parsetree, List *activeRIRs, bool forUpdatePushedDown)
  * not just "NOT x" which the planner is much smarter about, else we will
  * do the wrong thing when the qual evaluates to NULL.)
  *
- * The rule_qual may contain references to OLD or NEW.	OLD references are
+ * The rule_qual may contain references to OLD or NEW.  OLD references are
  * replaced by references to the specified rt_index (the relation that the
  * rule applies to).  NEW references are only possible for INSERT and UPDATE
  * queries on the relation itself, and so they should be replaced by copies
@@ -1803,7 +1803,7 @@ CopyAndAddInvertedQual(Query *parsetree,
  * rows that the qualified action doesn't act on.  (If there are multiple
  * qualified INSTEAD rules, we AND all the negated quals onto a single
  * modified original query.)  We won't execute the original, unmodified
- * query if we find either qualified or unqualified INSTEAD rules.	If
+ * query if we find either qualified or unqualified INSTEAD rules.  If
  * we find both, the modified original query is discarded too.
  */
 static List *
@@ -1961,7 +1961,7 @@ view_has_instead_trigger(Relation view, CmdType event)
  *
  * Caller must have verified that relation is a view!
  *
- * Note that the checks performed here are local to this view.	We do not
+ * Note that the checks performed here are local to this view.  We do not
  * check whether the view's underlying base relation is updatable; that
  * will be dealt with in later, recursive processing.
  *
@@ -2051,7 +2051,7 @@ view_is_auto_updatable(Relation view)
 	 * columns of the base relation, and no two should refer to the same
 	 * column.
 	 *
-	 * Note however that we should ignore resjunk entries.	This proviso is
+	 * Note however that we should ignore resjunk entries.  This proviso is
 	 * relevant because ORDER BY is not disallowed, and we shouldn't reject a
 	 * view defined like "SELECT * FROM t ORDER BY a+b".
 	 */
@@ -2091,7 +2091,7 @@ view_is_auto_updatable(Relation view)
  * relation supports.
  *
  * This is used for the information_schema views, which have separate concepts
- * of "updatable" and "trigger updatable".	A relation is "updatable" if it
+ * of "updatable" and "trigger updatable".  A relation is "updatable" if it
  * can be updated without the need for triggers (either because it has a
  * suitable RULE, or because it is simple enough to be automatically updated).
  * A relation is "trigger updatable" if it has a suitable INSTEAD OF trigger.
@@ -2103,7 +2103,7 @@ view_is_auto_updatable(Relation view)
  * to have trigger updatability included in the result.
  *
  * The return value is a bitmask of rule event numbers indicating which of
- * the INSERT, UPDATE and DELETE operations are supported.	(We do it this way
+ * the INSERT, UPDATE and DELETE operations are supported.  (We do it this way
  * so that we can test for UPDATE plus DELETE support in a single call.)
  */
 int
@@ -2315,7 +2315,7 @@ adjust_view_column_set(Bitmapset *cols, List *targetlist)
  *	  the view's base relation becomes the target relation.
  *
  * Note that the base relation here may itself be a view, which may or may not
- * have INSTEAD OF triggers or rules to handle the update.	That is handled by
+ * have INSTEAD OF triggers or rules to handle the update.  That is handled by
  * the recursion in RewriteQuery.
  */
 static Query *
@@ -2467,7 +2467,7 @@ rewriteTargetView(Query *parsetree, Relation view)
 	 * that does not correspond to what happens in ordinary SELECT usage of a
 	 * view: all referenced columns must have read permission, even if
 	 * optimization finds that some of them can be discarded during query
-	 * transformation.	The flattening we're doing here is an optional
+	 * transformation.  The flattening we're doing here is an optional
 	 * optimization, too.  (If you are unpersuaded and want to change this,
 	 * note that applying adjust_view_column_set to view_rte->selectedCols is
 	 * clearly *not* the right answer, since that neglects base-rel columns
@@ -2770,7 +2770,7 @@ RewriteQuery(Query *parsetree, List *rewrite_events)
 
 			/*
 			 * At this point product_queries contains any DO ALSO rule
-			 * actions. Add the rewritten query before or after those.	This
+			 * actions. Add the rewritten query before or after those.  This
 			 * must match the handling the original query would have gotten
 			 * below, if we allowed it to be included again.
 			 */
@@ -2990,7 +2990,7 @@ QueryRewrite(Query *parsetree)
 	 *
 	 * If the original query is still in the list, it sets the command tag.
 	 * Otherwise, the last INSTEAD query of the same kind as the original is
-	 * allowed to set the tag.	(Note these rules can leave us with no query
+	 * allowed to set the tag.  (Note these rules can leave us with no query
 	 * setting the tag.  The tcop code has to cope with this by setting up a
 	 * default tag based on the original un-rewritten query.)
 	 *