Skip site navigation (1) Skip section navigation (2)

Re: bug fix request

From: Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: bug fix request
Date: 2004-11-29 07:58:21
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
> Hmm.  This error is not coming from "a line of the copy", it is occurring
> because the COPY command itself fails, and so the server never tells
> psql to shift into COPY mode.  I'm not sure that a reasonable fix for
> this is possible.  As a counterexample, if you misspelled COPY as COPZ,
> would you expect the software to decide that following lines up to
> \. should be ignored?  If you manually misentered a COPY command and got
> an error, would you be surprised to have psql ignore everything you
> typed until you typed \. ?  (I can bet we'd get bug reports about that.)

Hmmm...doesn't stop it being annoying, however.

I presumed I was replicating the same problem I get when running SQL 
scripts that insert a few million rows.  Basically I start it running, 
then maybe some command before the COPY fails, then it gets to the COPY 
anyway and start barfing millions of lines.  Then I have to change my 
terminal settings to record heaps of lines and then try to ctrl-C the 
query before it scrolls too far off, just to find out the line that 
caused the error.

I guess the kind of difference in this case to me is that it's in a 
transaction, and the only "error" that the COPY command causes is that 
it's runnning in a rolled-back transaction.

Low tech I know...but it's kind of annoying :)


In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2004-11-29 08:04:38
Subject: Re: multiline CSV fields
Previous:From: Tom LaneDate: 2004-11-29 07:49:37
Subject: Re: bug fix request

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group