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.klaver@aklaver.com
