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 4a35a3f8a64..114d2ea588a 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
--
GitLab