Re: Bug in pg_dump/restore -o

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> I am told this was broken in 7.1 too.

Good point. That probably means it's not a "must fix" for 7.2, but
still, it'd be nice to have a solution.

Attached is a diff that seems to actually work in all three pgdump modes
(script output, -Fc, -Ft). A disadvantage of this approach is that
there doesn't seem to be any clean way to issue a DROP for the temp
table, so it will persist in the target database until we finish the
psql script or pg_restore run (or at least until we have to do a
\connect). This would create a problem if the name pgdump_oid
conflicted with any actual table name being restored. We could choose
some more bizarre name to reduce the probability of such a conflict.

A potentially more serious problem is that if the archiving code chooses
to issue other operations between the schema restore and data restore
for the temp table, we might do a \connect and lose the temp table.
Come to think of it, a data-only restore request won't work either.

I had originally tried a single data-only archive entry with copy
command CREATE... COPY. This would avoid the latter two problems.
However, while it seemed to work okay in -Fc mode, -Ft blew up:

$ pg_dump -Ft -b -o test >/tmp/dump.tar
pg_dump: [tar archiver] bad COPY statement - could not find "copy" in string "cr
eate temporary table pgdump_oid (dummy int4);
copy pgdump_oid with oids from stdin;

Philip, is this a fundamental problem, or do we just need to make
the tar archiver a little smarter about looking at the COPY strings?

regards, tom lane