Re: Modified pg_dump & new pg_restore need testing... - Mailing list pgsql-hackers
From | The Hermit Hacker |
---|---|
Subject | Re: Modified pg_dump & new pg_restore need testing... |
Date | |
Msg-id | Pine.BSF.4.21.0006301349080.773-100000@thelab.hub.org Whole thread Raw |
In response to | Modified pg_dump & new pg_restore need testing... (Philip Warner <pjw@rhyme.com.au>) |
Responses |
Re: Modified pg_dump & new pg_restore need testing...
|
List | pgsql-hackers |
Sounds like something that is a suitable replacement for what we have now ... I particularly like the 'compressed output' *but* is there some way, for the paranoid, of doing an uncompressed format (--dont-compress?)? Then again, how does this handle someone wanting to dump the database for reloading into a non-PgSQL database? On Fri, 30 Jun 2000, Philip Warner wrote: > > If anyone is interested in being sent the current sources for the new > pg_dump & pg_restore, please let me know. > > The utilities now seem to work, but need testing. > > The basic idea is to use pg_dump to dump an *entire* database, and then use > pg_restore to choose what is restored. > > The salient features are as follows: > > - pg_dump still used to dump database; all output is via new interface > (virtually all of the pg_dump code is changed, but not the logic). The > changes are relatively minor, all the same. > > - the '-c' option is not used in pg-dump: it now dumps the commands to > delete the schema, and it is up to the user of pg_restore to decide if they > are output. > > - the default output file format is a custom format with compressed > sections (the data dumps). It is NOT a text file. > > - pg_restore reads the backup file and, depending on the options chosen, > produces a script (to stdout) that can be sent to psql. > > - by default pg_restore outputs the schema/data in the order it was sent > from pg_dump, but the --oid flag will send the output in order of > increasing OID, and the --rearrange flag will put all 'non-parental' (??) > items at the end, after the data. (eg. indexes, acls, triggers etc). > Needless to say that the best results com from using both of these options. > > - If the -c (clear) option is chosen in pg_restore, it also dumps the > 'drop' commands in reverse order at the start of the script. This *should* > make it more reliable than dumping them when the item is defined. It also > means that triggers can be dropped. > > - The --toc option shows a summary of the restore operation that would be > performed if the --toc were not there. > > Please send me an email if you are interested and have the time to test them. > > Thanks, > > Philip Warner. > > > ---------------------------------------------------------------- > Philip Warner | __---_____ > Albatross Consulting Pty. Ltd. |----/ - \ > (A.C.N. 008 659 498) | /(@) ______---_ > Tel: (+61) 0500 83 82 81 | _________ \ > Fax: (+61) 0500 83 82 82 | ___________ | > Http://www.rhyme.com.au | / \| > | --________-- > PGP key available upon request, | / > and from pgp5.ai.mit.edu:11371 |/ > Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
pgsql-hackers by date: