Postgres Pro
Downloads
Home   >   mailing lists

Thread: COPY

COPY

From
Theo Kramer
Date:
Hi

I've been doing some big imports using COPY. Problem I have is COPY
aborting if a field could not be parsed. What's the feeling about
changing the behaviour so it does not abort, yet writes the offending line
number to the error log and continues with the next line?

I'm happy to do this if the above mentioned behaviour is acceptable.
--------
Regards
Theo

Re: [HACKERS] COPYz

From
Marc Howard Zuckman
Date:
On Fri, 13 Aug 1999, Theo Kramer wrote:

> Hi
> 
> I've been doing some big imports using COPY. Problem I have is COPY
> aborting if a field could not be parsed. What's the feeling about
> changing the behaviour so it does not abort, yet writes the offending line
> number to the error log and continues with the next line?
> 
My feeling is that the suggested enhancement would save me 
hours of work.

Marc Zuckman
marc@fallon.classyad.com

________________________________
_     Visit The Home and Condo MarketPlace              _
_          http://www.ClassyAd.com                  _
_                                  _
_  FREE basic property listings/advertisements and searches.  _
_                                  _
_  Try our premium, yet inexpensive services for a real          _
_   selling or buying edge!                      _
________________________________

Re: [HACKERS] COPY

From
Tom Lane
Date:
Theo Kramer <theo@flame.co.za> writes:
> I've been doing some big imports using COPY. Problem I have is COPY
> aborting if a field could not be parsed. What's the feeling about
> changing the behaviour so it does not abort, yet writes the offending line
> number to the error log and continues with the next line?

I can think of situations where you'd want it either way.  (For example,
in a pg_dump restore script I'd sure want big red warning flags if there
were any problems, not a piddly little message in the postmaster log...)

How about creating a SET variable that chooses either the above behavior
or the existing one?

If that seems acceptable all 'round, we can start arguing about which
way ought to be the default ;-)
        regards, tom lane

Re: [HACKERS] COPY

From
Theo Kramer
Date:
Tom Lane wrote:
> I can think of situations where you'd want it either way.  (For example,
> in a pg_dump restore script I'd sure want big red warning flags if there
> were any problems, not a piddly little message in the postmaster log...)
> 
> How about creating a SET variable that chooses either the above behavior
> or the existing one?
> 
> If that seems acceptable all 'round, we can start arguing about which
> way ought to be the default ;-)

Sounds good to me. I'll start looking at whats involved.
--------
Regards
Theo