From afcc6fbb6034cd37aa518b29e5684df35c179ffa Mon Sep 17 00:00:00 2001
From: Neil Conway <neilc@samurai.com>
Date: Tue, 17 Feb 2004 23:56:07 +0000
Subject: [PATCH] Remove a caveat from the "backup" documentation: pg_dump now
 does a better job of handling dependencies between database objects.

---
 doc/src/sgml/backup.sgml | 18 +-----------------
 1 file changed, 1 insertion(+), 17 deletions(-)

diff --git a/doc/src/sgml/backup.sgml b/doc/src/sgml/backup.sgml
index 4a35a3f8a6..114d2ea588 100644
--- a/doc/src/sgml/backup.sgml
+++ b/doc/src/sgml/backup.sgml
@@ -1,5 +1,5 @@
 <!--
-$PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.36 2004/02/17 09:07:16 neilc Exp $
+$PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.37 2004/02/17 23:56:07 neilc Exp $
 -->
 <chapter id="backup">
  <title>Backup and Restore</title>
@@ -270,22 +270,6 @@ pg_dump -Fc <replaceable class="parameter">dbname</replaceable> > <replaceable c
   <sect2 id="backup-dump-caveats">
    <title>Caveats</title>
 
-   <para>
-    <application>pg_dump</> (and by implication
-    <application>pg_dumpall</>) has a few limitations which stem from
-    the difficulty of reconstructing certain information from the system
-    catalogs.
-   </para>
-
-   <para>
-    Specifically, the order in which <application>pg_dump</> writes
-    the objects is not very sophisticated. This can lead to problems
-    for example when functions are used as column default values. The
-    only answer is to manually reorder the dump. If you created
-    circular dependencies in your schema then you will have more work
-    to do.
-   </para>
-
    <para>
     For reasons of backward compatibility, <application>pg_dump</>
     does not dump large objects by default.<indexterm><primary>large