Decibel! <decibel@decibel.org> writes:
> When restoring from pg_dump(all), if a problem occurs in a COPY
> command you're going to get a whole slew of errors, because as soon
> as COPY detects a problem it will throw an error and psql will
> immediately switch to trying to process the remaining data that was
> meant for COPY as if it was psql commands. This is confusing and
> annoying at best; it could conceivably trash data at worst (picture
> dumping a table that had SQL commands in it).
This is nonsense; it hasn't worked that way since we went to v3
protocol.
What is true is that if the COPY command itself is thoroughly borked,
the backend never tells psql to switch into COPY mode in the first
place.
> My idea to avoid this situation is to add an option to COPY that
> tells it not to throw an error until it runs out of input data.
This will not solve the problem, since again it only works if the COPY
command gets to execution.
Perhaps we could improve matters by having pg_dump issue \copy instead
of COPY and tweaking psql \copy (when non-interactive) to switch to
COPY-mode even if the backend rejects the command. I seem to recall
though that there was some reason for sticking to the COPY command form.
In the meantime, pg_restore direct to DB is reasonably proof against the
problem anyway ...
regards, tom lane