Date: Wed, 13 Apr 2022 12:40:56 -0500
From: Justin Pryzby <pryzby@telsasoft.com>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: David Rowley <dgrowleyml@gmail.com>, pgsql-hackers@postgresql.org,
	Fabien COELHO <coelho@cri.ensmp.fr>
Subject: Re: typos
Message-ID: <20220413174056.GQ26620@telsasoft.com>
References: 
 <CAApHDvq8pGRVyBJqKi+A3k_uocQOsE6iO36ixY7a1V9R1gbbHg@mail.gmail.com>
 <202204131729.g27uwttzzgao@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="6b3yLyRKT1M6kiA0"
Content-Disposition: inline
In-Reply-To: <202204131729.g27uwttzzgao@alvherre.pgsql>
User-Agent: Mutt/1.9.4 (2018-02-28)
Archived-At: 
 <https://www.postgresql.org/message-id/20220413174056.GQ26620%40telsasoft.com>
Precedence: bulk


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

On Wed, Apr 13, 2022 at 07:29:34PM +0200, Alvaro Herrera wrote:
> On 2022-Apr-11, David Rowley wrote:
> 
> > and also skipped:
> > 0016 (unsure if we should change these of pgindent is not touching it)
> > 0017 (unsure if we should change these of pgindent is not touching it)
> 
> I verified that pgindent will indeed not touch these changes by running
> before and after.  (I accepted one comment placement from that run that
> touched a neighboring line.)
> 
> I think pgindent is right not to modify vertical space very much, since
> in many cases it amounts to a subjective decision.  The patch seemed a
> (small) improvement, and it seems hard to make too much of a fuss about
> such things.  Pushed them as a single commit.
> 
> I hadn't noticed that Justin had posted a refreshed patch series, so I
> don't know if the new ones match what I pushed.

There were no changes - I had resent the patches that removed blank lines so it
was apparent that they were "outstanding" / under discussion.

There's (only) a few remaining.

--6b3yLyRKT1M6kiA0
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment; filename="0001-comment-spaces.patch"

From 543b9d77763da814cf1a99938252eb16a0a7d131 Mon Sep 17 00:00:00 2001
From: Justin Pryzby <pryzbyj@telsasoft.com>
Date: Sat, 12 Mar 2022 14:55:18 -0600
Subject: [PATCH 1/4] comment spaces

---
 src/backend/storage/file/fd.c     | 2 +-
 src/include/replication/message.h | 2 +-
 src/include/tsearch/ts_type.h     | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/backend/storage/file/fd.c b/src/backend/storage/file/fd.c
index 14b77f28617..24704b6a023 100644
--- a/src/backend/storage/file/fd.c
+++ b/src/backend/storage/file/fd.c
@@ -912,7 +912,7 @@ InitFileAccess(void)
 void
 InitTemporaryFileAccess(void)
 {
-	Assert(SizeVfdCache != 0);	/* InitFileAccess() needs to have run*/
+	Assert(SizeVfdCache != 0);	/* InitFileAccess() needs to have run */
 	Assert(!temporary_files_allowed);	/* call me only once */
 
 	/*
diff --git a/src/include/replication/message.h b/src/include/replication/message.h
index 7d7785292f1..b9686c28550 100644
--- a/src/include/replication/message.h
+++ b/src/include/replication/message.h
@@ -32,7 +32,7 @@ typedef struct xl_logical_message
 extern XLogRecPtr LogLogicalMessage(const char *prefix, const char *message,
 									size_t size, bool transactional);
 
-/* RMGR API*/
+/* RMGR API */
 #define XLOG_LOGICAL_MESSAGE	0x00
 void		logicalmsg_redo(XLogReaderState *record);
 void		logicalmsg_desc(StringInfo buf, XLogReaderState *record);
diff --git a/src/include/tsearch/ts_type.h b/src/include/tsearch/ts_type.h
index a2008f5504b..689b2d1cfb6 100644
--- a/src/include/tsearch/ts_type.h
+++ b/src/include/tsearch/ts_type.h
@@ -171,7 +171,7 @@ typedef struct
 
 extern PGDLLIMPORT const int tsearch_op_priority[OP_COUNT];
 
-/* get operation priority  by its code*/
+/* get operation priority by its code */
 #define OP_PRIORITY(x)	( tsearch_op_priority[(x) - 1] )
 /* get QueryOperator priority */
 #define QO_PRIORITY(x)	OP_PRIORITY(((QueryOperator *) (x))->oper)
-- 
2.17.1


--6b3yLyRKT1M6kiA0
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment; filename="0002-doc-review-locales.patch"

From e84373bd78d6634781536a96a083cf26c87aa53e Mon Sep 17 00:00:00 2001
From: Justin Pryzby <pryzbyj@telsasoft.com>
Date: Fri, 25 Mar 2022 13:04:48 -0500
Subject: [PATCH 3/4] doc review: locales

f2553d43060edb210b36c63187d52a632448e1d2
---
 doc/src/sgml/charset.sgml    | 12 ++++++------
 doc/src/sgml/ref/initdb.sgml |  2 +-
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/doc/src/sgml/charset.sgml b/doc/src/sgml/charset.sgml
index d60d3207fd4..b95303fb893 100644
--- a/doc/src/sgml/charset.sgml
+++ b/doc/src/sgml/charset.sgml
@@ -314,7 +314,7 @@ initdb --locale=sv_SE
       A locale can be selected separately for each database.  The SQL command
       <command>CREATE DATABASE</command> and its command-line equivalent
       <command>createdb</command> have options for that.  Use this for example
-      if a database cluster houses databases for multiple tennants with
+      if a database cluster houses databases for multiple tenants with
       different requirements.
      </para>
     </listitem>
@@ -346,7 +346,7 @@ initdb --locale=sv_SE
     providers</firstterm>.  This specifies which library supplies the locale
     data.  One standard provider name is <literal>libc</literal>, which uses
     the locales provided by the operating system C library.  These are the
-    locales that most tools provided by the operating system use.  Another
+    locales used by most tools provided by the operating system.  Another
     provider is <literal>icu</literal>, which uses the external
     ICU<indexterm><primary>ICU</primary></indexterm> library.  ICU locales can
     only be used if support for ICU was configured when PostgreSQL was built.
@@ -361,8 +361,8 @@ initdb --locale=sv_SE
 <programlisting>
 initdb --locale-provider=icu --icu-locale=en
 </programlisting>
-    See the description of the respective commands and programs for the
-    respective details.  Note that you can mix locale providers on different
+    See the description of the respective commands and programs for
+    details.  Note that you can mix locale providers at different
     granularities, for example use <literal>libc</literal> by default for the
     cluster but have one database that uses the <literal>icu</literal>
     provider, and then have collation objects using either provider within
@@ -610,8 +610,8 @@ SELECT * FROM test1 ORDER BY a || b COLLATE "fr_FR";
     definition has a <firstterm>provider</firstterm> that specifies which
     library supplies the locale data.  One standard provider name
     is <literal>libc</literal>, which uses the locales provided by the
-    operating system C library.  These are the locales that most tools
-    provided by the operating system use.  Another provider
+    operating system C library.  These are the locales used by most tools
+    provided by the operating system.  Another provider
     is <literal>icu</literal>, which uses the external
     ICU<indexterm><primary>ICU</primary></indexterm> library.  ICU locales can only be
     used if support for ICU was configured when PostgreSQL was built.
diff --git a/doc/src/sgml/ref/initdb.sgml b/doc/src/sgml/ref/initdb.sgml
index f5d633b0afa..c9ffaaecfb9 100644
--- a/doc/src/sgml/ref/initdb.sgml
+++ b/doc/src/sgml/ref/initdb.sgml
@@ -108,7 +108,7 @@ PostgreSQL documentation
    Alternatively, the ICU library can be used to provide locale services.
    (Again, this only sets the default for subsequently created databases.)  To
    select this option, specify <literal>--locale-provider=icu</literal>.
-   To chose the specific ICU locale ID to apply, use the option
+   To choose the specific ICU locale ID to apply, use the option
    <option>--icu-locale</option>.  Note that
    for implementation reasons and to support legacy code,
    <command>initdb</command> will still select and initialize libc locale
-- 
2.17.1


--6b3yLyRKT1M6kiA0
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
 filename="0003-doc-review-row-filters-for-logical-replication.patch"

From 7ebb9ee1761df8a9379e128e2d899a75d28ad2a7 Mon Sep 17 00:00:00 2001
From: Justin Pryzby <pryzbyj@telsasoft.com>
Date: Fri, 25 Mar 2022 12:22:58 -0500
Subject: [PATCH 4/4] doc review: row filters for logical replication

52e4f0cd472d39d07732b99559989ea3b615be78
---
 doc/src/sgml/ref/create_publication.sgml | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/src/sgml/ref/create_publication.sgml b/doc/src/sgml/ref/create_publication.sgml
index fb2d013393b..f4b44d99a88 100644
--- a/doc/src/sgml/ref/create_publication.sgml
+++ b/doc/src/sgml/ref/create_publication.sgml
@@ -252,8 +252,8 @@ CREATE PUBLICATION <replaceable class="parameter">name</replaceable>
    system columns.
    If your publication contains a partitioned table, the publication parameter
    <literal>publish_via_partition_root</literal> determines if it uses the
-   partition's row filter (if the parameter is false, the default) or the root
-   partitioned table's row filter.
+   partition's row filter (when the parameter is false, which is the default)
+   or the root partitioned table's row filter.
   </para>
 
   <para>
-- 
2.17.1


--6b3yLyRKT1M6kiA0--