Mention that pg_dump does not dump ALTER DATABASE ... SET commands;

backpatch to 8.3.X. Also fix markup that had just one bullet.

diff --git a/doc/src/sgml/ref/pg_dump.sgml b/doc/src/sgml/ref/pg_dump.sgml
index c8aae47b6f043dd495f65112030a2300d1bab518..39c64af810878063a16abf5b77b6f658487ea4aa 100644 (file)
--- a/doc/src/sgml/ref/pg_dump.sgml
+++ b/doc/src/sgml/ref/pg_dump.sgml
@@ -1,5 +1,5 @@
 
 
@@ -754,22 +754,13 @@ CREATE DATABASE foo WITH TEMPLATE template0;
   
 
   
-   pg_dump has a few limitations:
-
-   
-    
-     
-      When a data-only dump is chosen and the option
-      --disable-triggers is used,
-      pg_dump emits commands to disable
-      triggers on user tables before inserting the data and commands
-      to re-enable them after the data has been inserted.  If the
-      restore is stopped in the middle, the system catalogs might be
-      left in the wrong state.
-     
-    
-
-   
+   pg_dump has a limitation; when a
+   data-only dump is chosen and the option --disable-triggers
+   is used, pg_dump emits commands
+   to disable triggers on user tables before inserting the data
+   and commands to re-enable them after the data has been
+   inserted.  If the restore is stopped in the middle, the system
+   catalogs might be left in the wrong state.
   
 
   
@@ -782,11 +773,14 @@ CREATE DATABASE foo WITH TEMPLATE template0;
   
 
   
-   The dump file produced by pg_dump does
-   not contain the statistics used by the optimizer to make query
-   planning decisions.  Therefore, it is wise to run
-   ANALYZE after restoring from a dump file to
-   ensure good performance.
+   The dump file produced by pg_dump
+   does not contain the statistics used by the optimizer to make
+   query planning decisions.  Therefore, it is wise to run
+   ANALYZE after restoring from a dump file
+   to ensure good performance.  The dump file also does not
+   contain any ALTER DATABASE ... SET commands;
+   these settings are dumped by ,
+   along with database users and other installation-wide settings.