On 06/05/2017 05:15 PM, Ken Tanzer wrote:
Thanks Adrian and David. That all makes sense, and I gather the answer
regarding the existing dumps is "no, they can't be restored." So be
it. Here's a couple of follow-on comments::
Ideally figure out how to write an actual FK constraint - otherwise
use triggers.
I can't really make this an FK. I can (and probably will) put this into
a trigger. Although it seems like an extra layer of wrapping just to
call a function. I'm curious if there's any conceptual reason why
constraints couldn't (as an option) be restored after all the data is
loaded, and whether there would be any negative consequences of that? I
could see if your data still didn't pass the CHECKs, it's already
loaded. But the constraint could then be marked not valid?
Not sure why just know that if I stay within the guidelines it works, if
I do not its does not work:)
-1; pg_dump should not be trying to restore things. The core
developers shouldn't really concern themselves with the various and
sundry ways people might want to setup such a process. You have
tools for dump, and tools for restore, and you can combine them in
whatever fashion you deem useful. Or otherwise acquire someone
else's ideas.
I get that as a general principle. OTOH, being able to restore your
backups isn't just a random or inconsequential feature. I have access
to the superuser and can create DBs, but users in more locked down
scenarios might not be able to do so.
See that, but in your scenario you wanted to create a 'scratch' database
so you are back to a user with privileges. Then there is the whole
overhead of doing a restore twice. Basically, if you have no way to test
your backup/restore procedure before hand you are flying blind.
--
Adrian Klaver
adrian.kla...@aklaver.com
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
