At 17:27 17/01/02 -0500, Tom Lane wrote:
>
>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'm around now; do you still want me to look into this?
>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.
This leads me to the question: when should the OID restoration be performed
- in the SCHEMA or DATA phase? ISTM that it is part of the data, and should
be performed after data restoration. But perhaps I misunderstand what it is
for.
>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?
I need to look into this; there should be no difference.
>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;
I'm not sure, from your patch code, how it got the CREATE and COPY
statements in the one string - did you by any chance use an defective dump
file from a previous patch attempt?
Bye for now,
Philip.
----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.B.N. 75 008 659 498) | /(@) ______---_
Tel: (+61) 0500 83 82 81 | _________ \
Fax: (+61) 0500 83 82 82 | ___________ |
Http://www.rhyme.com.au | / \| | --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/
