Re: 7.5-dev, pg_dumpall, dollarquoting

> 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