> 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