|
1 | 1 | <!-- |
2 | | -$PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.36 2004/02/1709:07:16 neilc Exp $ |
| 2 | +$PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.37 2004/02/1723:56:07 neilc Exp $ |
3 | 3 | --> |
4 | 4 | <chapter id="backup"> |
5 | 5 | <title>Backup and Restore</title> |
@@ -270,22 +270,6 @@ pg_dump -Fc <replaceable class="parameter">dbname</replaceable> > <replaceable c |
270 | 270 | <sect2 id="backup-dump-caveats"> |
271 | 271 | <title>Caveats</title> |
272 | 272 |
|
273 | | - <para> |
274 | | - <application>pg_dump</> (and by implication |
275 | | - <application>pg_dumpall</>) has a few limitations which stem from |
276 | | - the difficulty of reconstructing certain information from the system |
277 | | - catalogs. |
278 | | - </para> |
279 | | - |
280 | | - <para> |
281 | | - Specifically, the order in which <application>pg_dump</> writes |
282 | | - the objects is not very sophisticated. This can lead to problems |
283 | | - for example when functions are used as column default values. The |
284 | | - only answer is to manually reorder the dump. If you created |
285 | | - circular dependencies in your schema then you will have more work |
286 | | - to do. |
287 | | - </para> |
288 | | - |
289 | 273 | <para> |
290 | 274 | For reasons of backward compatibility, <application>pg_dump</> |
291 | 275 | does not dump large objects by default.<indexterm><primary>large |
|
