On Mon, Jan 7, 2013 at 4:41 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Magnus Hagander <mag...@hagander.net> writes: >> On Mon, Jan 7, 2013 at 1:32 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> emes...@redhat.com writes: >>>> * restore.sql includes DROP statements for each object even tough -c flag >>>> was not given > >>> I believe this is intentional - at least, pg_backup_tar.c goes out of >>> its way to make it happen. (The forcible setting of ropt->dropSchema >>> in _CloseArchive is the cause, and it's hard to see why that would be >>> there unless the author intended this effect.) Perhaps we should remove >>> that, but it would be an incompatible change. Arguing for or against >>> it really requires a model of what people would be doing with the >>> restore.sql script. I'm not entirely convinced that it should be >>> considered equivalent to what you'd get from a plain dump run. > >> tar archives are more like custom archives ,arne't they? The idea >> being that since you use pg_restore to restore them, you should use -c >> on the pg_restore commandline, and not on the pg_dump one? And if we >> didn't include it in the dump, that wouldn't even be possible. > > No, pg_restore depends only on what is in the TOC data structure. > The restore.sql script is just an auxiliary file that's there if you > extract the contents of the tar file --- pg_restore doesn't use it.
Ah, so it's never used at all? Interesting. Shows how often I use the tar format :D AFAIK it has no actual advantage over custom format, but I guess including the restore.sql file might be considered such an advantage. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
