DOC: style changes in add-collprovider option

Author: Liudmila Mantrova

doc/src/sgml/ref/pg_dump.sgml

@@ -638,23 +638,22 @@ doc/src/sgml/ref/pg_dump.sgml
       </listitem>
      </varlistentry>
 
-     <varlistentry>
+      <varlistentry>
       <term><option>--add-collprovider</option></term>
       <listitem>
        <para>
-        This option is recommended when upgrading with
+        If the collation provider for the database to be dumped is implicit,
+        this option explicitly adds the collation provider to the dump.
+        This option is recommended if you are using
         <application>pg_dump</application> and
-        <application>pg_restore</application> from previous versions of
-        <productname>&project;</> as well as from all versions of
-        <productname>PostgreSQL</> (it's automatically used in case of a binary
-        upgrade; and it actually does nothing for the current version of
-        <productname>&project;</>). If you do not want to manually fix the
-        scripts (or do not know how to do it correctly) this helps to avoid mess
-        when the templated database and the created database actually use
-        different collation providers that are ommitted (see <xref
-        linkend="collation-managing">). In this case the check constrains that
+        <application>pg_restore</application> to upgrade from previous versions of
+        <productname>&project;</> or any version of <productname>PostgreSQL</>.
+        It allows to preserve the original collation provider for the migrated database if
+        the <literal>template0</literal> database in the new cluster uses different
+        collation settings. Otherwise, check constraints that
         use the default collation of the database may change and the
-        <command>COPY</command> command may end with fail.
+        <command>COPY</command> command may end with a failure.
+        For binary upgrades, this option is used automatically.
        </para>
       </listitem>
      </varlistentry>

doc/src/sgml/ref/pg_dumpall.sgml

@@ -231,23 +231,22 @@ doc/src/sgml/ref/pg_dumpall.sgml
       </listitem>
      </varlistentry>
 
-     <varlistentry>
+      <varlistentry>
       <term><option>--add-collprovider</option></term>
       <listitem>
        <para>
-        This option is recommended when upgrading with
+        If the collation provider for the database to be dumped is implicit,
+        this option explicitly adds the collation provider to the dump.
+        This option is recommended if you are using
         <application>pg_dumpall</application> and
-        <application>pg_restore</application> from previous versions of
-        <productname>&project;</> as well as from all versions of
-        <productname>PostgreSQL</> (it's automatically used in case of a binary
-        upgrade; and it actually does nothing for the current version of
-        <productname>&project;</>). If you do not want to manually fix the
-        scripts (or do not know how to do it correctly) this helps to avoid mess
-        when the templated database and the created database actually use
-        different collation providers that are ommitted (see <xref
-        linkend="collation-managing">). In this case the check constrains that
+        <application>pg_restore</application> to upgrade from previous versions of
+        <productname>&project;</> or any version of <productname>PostgreSQL</>.
+        It allows to preserve the original collation provider for the migrated database if
+        the <literal>template0</literal> database in the new cluster uses different
+        collation settings. Otherwise, check constraints that
         use the default collation of the database may change and the
-        <command>COPY</command> command may end with fail.
+        <command>COPY</command> command may end with a failure.
+        For binary upgrades, this option is used automatically.
        </para>
       </listitem>
      </varlistentry>