Re: Allow COPY from STDIN to absorb all input before throwing an error

Tom Lane wrote
> Decibel! <decibel(at)decibel(dot)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.

I had an annoying experience with COPY within psql yesterday.
I had a dump of just three tables, which I wanted to investigate. I tried loading them into an empty database, using psql's \i command.
The table creation failed as dependent tables/sequences where absent.
The copy command failed as the tables did not exist.
The data intended as the input to the copy statement resulted in a large number of error messages.

> > 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.

It is only now that I've found the \set ON_ERROR_STOP command, which I presume would have solved my problem.

Regards,
Stephen Denne.

Disclaimer:
At the Datamail Group we value team commitment, respect, achievement, customer focus, and courage. This email with any attachments is confidential and may be subject to legal privilege. If it is not intended for you please advise by reply immediately, destroy it and do not copy, disclose or use it in any way.
__________________________________________________________________
This email has been scanned by the DMZGlobal Business Quality
Electronic Messaging Suite.
Please see http://www.dmzglobal.com/dmzmessaging.htm for details.
__________________________________________________________________