Re: [PATCH] Remove trailing whitespaces from documentation

* Vladimir Rusinov (vrusinov(at)google(dot)com) wrote:
> They are considered bad practice in many style guides and many editors
> configured to stip them on every save.
>
> Such editors will produce spurious diffs when editing the documentation.
>
> Therefore, I propose this patch.

As mentioned down-thread, most of this is from psql output and I don't
know that we actually want to get rid of that whitespace. Ideally, we
could indicate that trailing whitespace should be preserved when
printing examples, either with the SGML or the XML format.

The (relativly few) ones I include below do look like cases we should
probably fix and back-patch (to simplify later back-patching efforts).
Most of these only go back to 9.6 (parallel.sgml) anyway.

Thanks!

Stephen

> diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
> index 0fc4e57..3b614b6 100644
> --- 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
> @@ -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 333b01d..8ea6624 100644
> --- 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 00c984d..9339826 100644
> --- 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 8efd51a..fea2196 100644
> --- 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
> --- 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">