Re: Bug in pg_dump/restore -o

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > I think I see the cause. I created a simple table and then generated
> > the dump. I found this that the normal table had its COPY data in
> > binary format while the max oid dump was pure ASCII. My guess is that
> > the max oid dump code isn't calling the right routine to dump its data.
>
> Indeed, the max oid dump code doesn't look like it's been clued at all
> about interoperating with the new pg_dump output code. It can't just
> intermix commands and data into one string and expect pg_restore to cope.
> Compare what happens in dumpClasses/dumpClasses_nodumpData to what's
> being done in setMaxOid.
>
> Philip, you're probably the best-qualified to fix this, but if you don't
> have time today then I can work on it. I don't want to delay RC1 for
> this...

I am told this was broken in 7.1 too.

Attached is a diff that shows a possible direction for a solution. What
I did was instead of doing the COPY myself, I am keeping the temp table
I just created and passing that table name to the standard dump routines
to do the COPY.

One problem is that there is no TableInfo for the table, but I can call
getTables() with the temp table name. Also, it is a temp table and I am
not sure if it is going to like that.

Anyway, this is not completed code but just a possible solution.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026