doc: Remove some trailing whitespace

Per discussion, we will not at this time remove trailing whitespace in
psql output displays where it is part of the actual psql output.

From: Vladimir Rusinov <vrusinov@google.com>

diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 0fc4e57d900b08c239be6b8f98626b59063b3ff6..3b614b6ecdf2bedcfa65fee04b813a18a1e5114b 100644 (file)
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -1181,7 +1181,7 @@ include_dir 'conf.d'
         it in plaintext. <literal>on</> and <literal>off</> are also accepted, as
         aliases for <literal>md5</> and <literal>plain</>, respectively.
        </para>
-       
+
       </listitem>
      </varlistentry>
 

diff --git a/doc/src/sgml/parallel.sgml b/doc/src/sgml/parallel.sgml
index cf4c1c9c2a9762b800ee79fbe3a819aa92642a66..bca4886b21e28e89c20001cbc5a2ce7241b4cd02 100644 (file)
--- a/doc/src/sgml/parallel.sgml
+++ b/doc/src/sgml/parallel.sgml
@@ -134,12 +134,12 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
 
   <itemizedlist>
     <listitem>
-      <para> 
+      <para>
         The query writes any data or locks any database rows. If a query
         contains a data-modifying operation either at the top level or within
         a CTE, no parallel plans for that query will be generated. This is a
         limitation of the current implementation which could be lifted in a
-        future release. 
+        future release.
       </para>
     </listitem>
 
@@ -153,7 +153,7 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
         <literal>FOR x IN query LOOP .. END LOOP</literal> will never use a
         parallel plan, because the parallel query system is unable to verify
         that the code in the loop is safe to execute while parallel query is
-        active. 
+        active.
       </para>
     </listitem>
 
@@ -174,7 +174,7 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
         query itself, that query will never use a parallel plan. This is a
         limitation of the current implementation, but it may not be desirable
         to remove this limitation, since it could result in a single query
-        using a very large number of processes. 
+        using a very large number of processes.
       </para>
     </listitem>
 
@@ -197,7 +197,7 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
 
   <itemizedlist>
     <listitem>
-      <para> 
+      <para>
         No background workers can be obtained because of the limitation that
         the total number of background workers cannot exceed
         <xref linkend="guc-max-worker-processes">.
@@ -205,7 +205,7 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
     </listitem>
 
     <listitem>
-      <para> 
+      <para>
         No background workers can be obtained because of the limitation that
         the total number of background workers launched for purposes of
         parallel query cannot exceed <xref linkend="guc-max-parallel-workers">.
@@ -213,7 +213,7 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
     </listitem>
 
     <listitem>
-      <para> 
+      <para>
         The client sends an Execute message with a non-zero fetch count.
         See the discussion of the
         <link linkend="protocol-flow-ext-query">extended query protocol</link>.
@@ -228,7 +228,7 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
     </listitem>
 
     <listitem>
-      <para> 
+      <para>
         A prepared statement is executed using a <literal>CREATE TABLE .. AS
         EXECUTE ..</literal> statement.  This construct converts what otherwise
         would have been a read-only operation into a read-write operation,
@@ -237,7 +237,7 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
     </listitem>
 
     <listitem>
-      <para> 
+      <para>
         The transaction isolation level is serializable.  This situation
         does not normally arise, because parallel query plans are not
         generated when the transaction isolation level is serializable.
@@ -467,7 +467,7 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
     transaction. If you write a function which does this, and this behavior
     difference is important to you, mark such functions as
     <literal>PARALLEL RESTRICTED</literal>
-    to ensure that they execute only in the leader. 
+    to ensure that they execute only in the leader.
   </para>
 
   <para>
@@ -475,7 +475,7 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
     parallel-restricted functions or aggregates involved in the query in
     order to obtain a superior plan.  So, for example, if a <literal>WHERE</>
     clause applied to a particular table is parallel restricted, the query
-    planner will not consider placing the scan of that table below a 
+    planner will not consider placing the scan of that table below a
     <literal>Gather</> node.  In some cases, it would be
     possible (and perhaps even efficient) to include the scan of that table in
     the parallel portion of the query and defer the evaluation of the

diff --git a/doc/src/sgml/ref/alter_table.sgml b/doc/src/sgml/ref/alter_table.sgml
index 333b01db36e836a4cd18b3f0c4aaa2c0fd631a94..8ea66241470f9d98f60386f7e935102c2fe63fc3 100644 (file)
--- a/doc/src/sgml/ref/alter_table.sgml
+++ b/doc/src/sgml/ref/alter_table.sgml
@@ -1121,7 +1121,7 @@ ALTER TABLE [ IF EXISTS ] <replaceable class="PARAMETER">name</replaceable>
     Also, because selecting from the parent also selects from its descendents,
     a constraint on the parent cannot be marked valid unless it is also marked
     valid for those descendents.  In all of these cases, <command>ALTER TABLE
-    ONLY</command> will be rejected.  
+    ONLY</command> will be rejected.
    </para>
 
    <para>

diff --git a/doc/src/sgml/ref/insert.sgml b/doc/src/sgml/ref/insert.sgml
index 00c984d8d54e80312410f6f53a9f7f43ae887561..9339826818cf487ea315c60d3ccadaee9fc62d3e 100644 (file)
--- a/doc/src/sgml/ref/insert.sgml
+++ b/doc/src/sgml/ref/insert.sgml
@@ -526,7 +526,7 @@ INSERT <replaceable>oid</replaceable> <replaceable class="parameter">count</repl
    updated by the command.
   </para>
  </refsect1>
- 
+
  <refsect1>
   <title>Notes</title>
 

diff --git a/doc/src/sgml/ref/prepare.sgml b/doc/src/sgml/ref/prepare.sgml
index 8efd51aaec9cf82e84f03dd77d47b34146b90687..fea2196efee320428a0f908ae441229f66586830 100644 (file)
--- a/doc/src/sgml/ref/prepare.sgml
+++ b/doc/src/sgml/ref/prepare.sgml
@@ -73,7 +73,7 @@ PREPARE <replaceable class="PARAMETER">name</replaceable> [ ( <replaceable class
    Prepared statements potentially have the largest performance advantage
    when a single session is being used to execute a large number of similar
    statements. The performance difference will be particularly
-   significant if the statements are complex to plan or rewrite, e.g. 
+   significant if the statements are complex to plan or rewrite, e.g.
    if the query involves a join of many tables or requires
    the application of several rules. If the statement is relatively simple
    to plan and rewrite but relatively expensive to execute, the

diff --git a/doc/src/sgml/ref/reindexdb.sgml b/doc/src/sgml/ref/reindexdb.sgml
index 36df949c957ab60f26747e1e503e93bc2d5df458..e4721d81130b7625599a9fdd63adcb3e23fba350 100644 (file)
--- a/doc/src/sgml/ref/reindexdb.sgml
+++ b/doc/src/sgml/ref/reindexdb.sgml
@@ -24,7 +24,7 @@ PostgreSQL documentation
    <command>reindexdb</command>
    <arg rep="repeat"><replaceable>connection-option</replaceable></arg>
    <arg rep="repeat"><replaceable>option</replaceable></arg>
-   
+
    <arg choice="plain" rep="repeat">
     <arg choice="opt">
      <group choice="plain">