On 01/14/2014 06:06 AM, Day, David wrote:
Adrian,
Thanks for confirming my observations.
My hope was that I would be able to create one archive file with pg_dump -Fc,
which at a future time could be used to do either a total restoration
or partial restorations via options of pg_restore; ie. Not to have create
addeded specialized pg_dump for each recovery case.
I had as you suggested observed stdout of my test cases.
Actually my suggestion was to use -f which captures the restore into a
file. This creates something you can look at leisure:)
a.) pg_restore -c -t tbl1 -t tbl2 archive_file
There are no SQL CONSTRAINT or TRIGGER statements related to these
2 tables.
When I add the "-d my_db" it confirms that table is restored,
But with no constraints and no triggers.
b.) pg_restore -c -v -a -t tbl2 -t tbl2 archive_file
As previously noted I get verbose indication that the table data is being
dropped.
However there are no SQL commands that would cause that ( DELETE or TRUNCATE )
Yes, it is outputting dropping TABLE DATA, where TABLE DATA is a command
I am not familiar with and which does not show up in the dump file.
The attempt ends up failing as the table ends up with duplicated data.
This ( -a -c ) would be a nice combination of pg_restore as pg_dump as I recall
does not allow for that combination.
From what I see it does not actually 'drop' the table data, so you are
just doing a COPY over existing data.
Rgds
Dave
--
Adrian Klaver
adrian.kla...@gmail.com
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
