Re: Allow COPY from STDIN to absorb all input before throwing an error - Mailing list pgsql-hackers

From Stephen Denne
Subject Re: Allow COPY from STDIN to absorb all input before throwing an error
Date
Msg-id F0238EBA67824444BC1CB4700960CB4805110300@dmpeints002.isotach.com
Whole thread Raw
In response to Re: Allow COPY from STDIN to absorb all input before throwing an error  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Allow COPY from STDIN to absorb all input before throwing an error  (Decibel! <decibel@decibel.org>)
List pgsql-hackers
Tom Lane wrote
> 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.

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
attachmentsis 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
BusinessQuality             Electronic Messaging Suite. 
Please see http://www.dmzglobal.com/dmzmessaging.htm for details.
__________________________________________________________________




pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: [PATCHES] libpq type system 0.9a
Next
From: Alvaro Herrera
Date:
Subject: Re: Concurrent psql API