From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Cc: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> |
Subject: | Re: 7.5-dev, pg_dumpall, dollarquoting |
Date: | 2004-06-23 16:41:27 |
Message-ID: | 200406230941.27516.josh@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
KL-
> Would you be able to specify exactly the deficiences? It's my mission
> at the moment to make pg_dump 7.5 known-issue free :)
Well, since you asked:
(please excuse me if I'm covering old ground. I was off Hackers for almost a
month this spring)
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.
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?
--
Josh Berkus
Aglio Database Solutions
San Francisco
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Cohen | 2004-06-23 16:46:39 | Re: creating a cluster |
Previous Message | Jeroen T. Vermeulen | 2004-06-23 16:16:36 | PREPARE and transactions |