Date: Mon, 27 Sep 2021 19:50:02 -0500
From: Justin Pryzby <pryzby@telsasoft.com>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Michael Paquier <michael@paquier.xyz>, pgsql-hackers@postgresql.org,
	Tomas Vondra <tomas.vondra@enterprisedb.com>,
	Andres Freund <andres@anarazel.de>, Zhihong Yu <zyu@yugabyte.com>
Subject: Re: typos (and more)
Message-ID: <20210928005002.GM831@telsasoft.com>
References: <YVFVZn28+2+Hjbc2@paquier.xyz>
 <202109272104.7t253iw236fb@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="WFYXJKyHTUiGqOmp"
Content-Disposition: inline
In-Reply-To: <202109272104.7t253iw236fb@alvherre.pgsql>
User-Agent: Mutt/1.9.4 (2018-02-28)
Archived-At: 
 <https://www.postgresql.org/message-id/20210928005002.GM831%40telsasoft.com>
Precedence: bulk


--WFYXJKyHTUiGqOmp
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Mon, Sep 27, 2021 at 06:04:02PM -0300, Alvaro Herrera wrote:
> On 2021-Sep-27, Michael Paquier wrote:
> 
> > The use
> > of "statistic", "statistics" and "statistics object" in 0008 and 0012
> > is indeed inconsistent.  The latter term is the most used, but it
> > sounds a bit weird to me even if it refers to the DDL object
> > manipulated.  Simply using "statistics" would be tempting.
> 
> Initially we just used "statistic" as a noun, which IIRC was already
> grammatically wrong (but I didn't know that and I think Tomas didn't
> either); later at some point when discussing how to use that noun in
> plural we realized this and argued that merely using "statistics" was
> even more wrong.  It was then that we started using the term "statistics
> object" with plural "statistics objects".  Going back to using just
> "statistics" is unlikely to have become correct; I think Justin's
> patches 0008 and 0012 are correct.

Attached is an updated patch fixing more of the same.

-- 
Justin

--WFYXJKyHTUiGqOmp
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
 filename="0001-Refer-to-plural-statistics-OBJECTS.patch"

From 45c16e1cb6b3ddf007806f5942f3acf64a75edf7 Mon Sep 17 00:00:00 2001
From: Justin Pryzby <pryzbyj@telsasoft.com>
Date: Sun, 12 Sep 2021 23:45:05 -0500
Subject: [PATCH] Refer to plural statistics OBJECTS

See also: f04c9a61468904b6815b2bc73a48878817766e0e
---
 src/backend/commands/statscmds.c        | 14 +++++++-------
 src/backend/statistics/extended_stats.c | 12 ++++++------
 src/backend/utils/adt/selfuncs.c        | 12 ++++++------
 3 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/src/backend/commands/statscmds.c b/src/backend/commands/statscmds.c
index 9938b65083..13987d9dcb 100644
--- a/src/backend/commands/statscmds.c
+++ b/src/backend/commands/statscmds.c
@@ -431,7 +431,7 @@ CreateStatistics(CreateStatsStmt *stmt)
 	 * similar to why we don't bother with extracting columns from
 	 * expressions. It's either expensive or very easy to defeat for
 	 * determined user, and there's no risk if we allow such statistics (the
-	 * statistics is useless, but harmless).
+	 * statistic is useless, but harmless).
 	 */
 	foreach(cell, stxexprs)
 	{
@@ -560,7 +560,7 @@ CreateStatistics(CreateStatsStmt *stmt)
 	}
 
 	/*
-	 * If there are no dependencies on a column, give the statistics an auto
+	 * If there are no dependencies on a column, give the statistics object an auto
 	 * dependency on the whole table.  In most cases, this will be redundant,
 	 * but it might not be if the statistics expressions contain no Vars
 	 * (which might seem strange but possible). This is consistent with what
@@ -649,7 +649,7 @@ AlterStatistics(AlterStatsStmt *stmt)
 	stxoid = get_statistics_object_oid(stmt->defnames, stmt->missing_ok);
 
 	/*
-	 * If we got here and the OID is not valid, it means the statistics does
+	 * If we got here and the OID is not valid, it means the statistics object does
 	 * not exist, but the command specified IF EXISTS. So report this as a
 	 * simple NOTICE and we're done.
 	 */
@@ -768,7 +768,7 @@ RemoveStatisticsById(Oid statsOid)
 }
 
 /*
- * Select a nonconflicting name for a new statistics.
+ * Select a nonconflicting name for a new statistics object.
  *
  * name1, name2, and label are used the same way as for makeObjectName(),
  * except that the label can't be NULL; digits will be appended to the label
@@ -815,7 +815,7 @@ ChooseExtendedStatisticName(const char *name1, const char *name2,
 }
 
 /*
- * Generate "name2" for a new statistics given the list of column names for it
+ * Generate "name2" for a new statistics object given the list of column names for it
  * This will be passed to ChooseExtendedStatisticName along with the parent
  * table name and a suitable label.
  *
@@ -869,8 +869,8 @@ ChooseExtendedStatisticNameAddition(List *exprs)
 }
 
 /*
- * StatisticsGetRelation: given a statistics's relation OID, get the OID of
- * the relation it is an statistics on.  Uses the system cache.
+ * StatisticsGetRelation: given a statistics object's OID, get the OID of
+ * the relation it is defined on.  Uses the system cache.
  */
 Oid
 StatisticsGetRelation(Oid statId, bool missing_ok)
diff --git a/src/backend/statistics/extended_stats.c b/src/backend/statistics/extended_stats.c
index 4c35223457..97f4ba3590 100644
--- a/src/backend/statistics/extended_stats.c
+++ b/src/backend/statistics/extended_stats.c
@@ -182,7 +182,7 @@ BuildRelationExtStatistics(Relation onerel, double totalrows,
 			continue;
 		}
 
-		/* compute statistics target for this statistics */
+		/* compute statistics target for this statistics object */
 		stattarget = statext_compute_stattarget(stat->stattarget,
 												bms_num_members(stat->columns),
 												stats);
@@ -195,7 +195,7 @@ BuildRelationExtStatistics(Relation onerel, double totalrows,
 		if (stattarget == 0)
 			continue;
 
-		/* evaluate expressions (if the statistics has any) */
+		/* evaluate expressions (if the statistics object has any) */
 		data = make_build_data(onerel, stat, numrows, rows, stats, stattarget);
 
 		/* compute statistic of each requested type */
@@ -257,7 +257,7 @@ BuildRelationExtStatistics(Relation onerel, double totalrows,
  * when analyzing only some of the columns, this will skip statistics objects
  * that would require additional columns.
  *
- * See statext_compute_stattarget for details about how we compute statistics
+ * See statext_compute_stattarget for details about how we compute the statistics
  * target for a statistics object (from the object target, attribute targets
  * and default statistics target).
  */
@@ -329,7 +329,7 @@ ComputeExtStatisticsRows(Relation onerel,
  *
  * When computing target for extended statistics objects, we consider three
  * places where the target may be set - the statistics object itself,
- * attributes the statistics is defined on, and then the default statistics
+ * attributes the statistics object is defined on, and then the default statistics
  * target.
  *
  * First we look at what's set for the statistics object itself, using the
@@ -1789,8 +1789,8 @@ statext_mcv_clauselist_selectivity(PlannerInfo *root, List *clauses, int varReli
 
 			/*
 			 * The clause was not estimated yet, and we've extracted either
-			 * attnums of expressions from it. Ignore it if it's not fully
-			 * covered by the chosen statistics.
+			 * attnums or expressions from it. Ignore it if it's not fully
+			 * covered by the chosen statistics object.
 			 *
 			 * We need to check both attributes and expressions, and reject if
 			 * either is not covered.
diff --git a/src/backend/utils/adt/selfuncs.c b/src/backend/utils/adt/selfuncs.c
index 0c8c05f6c2..0e5fb83505 100644
--- a/src/backend/utils/adt/selfuncs.c
+++ b/src/backend/utils/adt/selfuncs.c
@@ -3443,7 +3443,7 @@ estimate_num_groups(PlannerInfo *root, List *groupExprs, double input_rows,
 		 * expression, treat it as a single variable even if it's really more
 		 * complicated.
 		 *
-		 * XXX This has the consequence that if there's a statistics on the
+		 * XXX This has the consequence that if there's a statistics object on the
 		 * expression, we don't split it into individual Vars. This affects
 		 * our selection of statistics in estimate_multivariate_ndistinct,
 		 * because it's probably better to use more accurate estimate for each
@@ -3918,7 +3918,7 @@ estimate_multivariate_ndistinct(PlannerInfo *root, RelOptInfo *rel,
 	if (!rel->statlist)
 		return false;
 
-	/* look for the ndistinct statistics matching the most vars */
+	/* look for the ndistinct statistics object matching the most vars */
 	nmatches_vars = 0;			/* we require at least two matches */
 	nmatches_exprs = 0;
 	foreach(lc, rel->statlist)
@@ -3964,7 +3964,7 @@ estimate_multivariate_ndistinct(PlannerInfo *root, RelOptInfo *rel,
 				continue;
 			}
 
-			/* expression - see if it's in the statistics */
+			/* expression - see if it's in the statistics object */
 			foreach(lc3, info->exprs)
 			{
 				Node	   *expr = (Node *) lfirst(lc3);
@@ -4053,7 +4053,7 @@ estimate_multivariate_ndistinct(PlannerInfo *root, RelOptInfo *rel,
 				if (!AttrNumberIsForUserDefinedAttr(attnum))
 					continue;
 
-				/* Is the variable covered by the statistics? */
+				/* Is the variable covered by the statistics object? */
 				if (!bms_is_member(attnum, matched_info->keys))
 					continue;
 
@@ -4075,7 +4075,7 @@ estimate_multivariate_ndistinct(PlannerInfo *root, RelOptInfo *rel,
 			if (found)
 				continue;
 
-			/* expression - see if it's in the statistics */
+			/* expression - see if it's in the statistics object */
 			idx = 0;
 			foreach(lc3, matched_info->exprs)
 			{
@@ -5276,7 +5276,7 @@ examine_variable(PlannerInfo *root, Node *node, int varRelid,
 					/*
 					 * For simplicity, we insist on the whole table being
 					 * selectable, rather than trying to identify which
-					 * column(s) the statistics depends on.  Also require all
+					 * column(s) the statistics object depends on.  Also require all
 					 * rows to be selectable --- there must be no
 					 * securityQuals from security barrier views or RLS
 					 * policies.
-- 
2.17.0


--WFYXJKyHTUiGqOmp--