1) When pg_dump 7.4.1 (I have not tested on CVS) pulls a dump from a 7.2 database with confusing dependancies (e.g. functions depend on views which depend on multiple tables and other views containing other functions), some objects (almost always functions) still get silently dropped from the dump file. This "silent dropping" was also a problem in 7.3 (pulling from 7.2), but nobody wanted to work on it -- especially as it's only possible to demonstrate with a sufficiently complex early 7.2 database.
I have a good test database for this, I will test with CVS.
Nothing gets silently dropped. It will cause an ERROR on creation and then keep going, but it won't silently drop it... (unless it's a binary dump thing...)
Anyway, pg_dump in CVS does correct dump ordering based on a topological sort of the pg_depend relation (thank Tom for that). It will of course only work on a 7.3 or higher backend.
2) pg_restore needs to be more tolerant with certain kinds of errors. For example, if an object already exists in the target database, due to being from template1, it should be possible to tell pg_restore to ignore the error with a switch. Currently, this issue prevents me from using pg_restore on some systems, where the restore isn't run as the superuser. Another switch, telling pg_restore to attempt to ignore all errors and restore anyway, would also be keen (though I can see potential abuse issues).
Has this already been addressed in CVS?
Hmmm, dunno about this - it wasn't on my radar really. I'll experiment with it, but I don't think I'm going to have time before June 30th :(
Chris
---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
