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: 41AAD69D.5000303@familyhealth.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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 :)

Chris

In response to

Responses

Browse pgsql-hackers by date

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