Re: COPY enhancements - Mailing list pgsql-hackers

From Emmanuel Cecchet
Subject Re: COPY enhancements
Date
Msg-id 4ADE08DF.7010605@asterdata.com
Whole thread Raw
In response to Re: COPY enhancements  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: COPY enhancements
List pgsql-hackers
Tom,
> Emmanuel Cecchet <manu@asterdata.com> writes:
>   
>> Tom Lane wrote:
>>     
>>> There aren't any.  You can *not* put a try/catch around arbitrary code
>>> without a subtransaction.  Don't even think about it
>> Well then why the tests provided with the patch are working?
>>     
> Because they carefully exercise only a tiny fraction of the system.
> The key word in my sentence above is "arbitrary".  You don't know what
> a datatype input function might try to do, let alone triggers or other
> functions that COPY might have to invoke.  They might do things that
> need to be cleaned up after, and subtransaction rollback is the only
> mechanism we have for that.
>   
Is it possible to use the try/catch mechanism to detect errors and log 
them and only abort the command at the end of the processing?
This would have the advantage of being to be able to log all errors 
without the overhead of subtransactions and even add some additional 
information on where the error happened (parsing, constraints, trigger, 
...) for further automated treatment. The result would still be clean 
since we would abort the COPY command in case of an error as it does 
currently (but we would not stop on the first error).
I guess that it would make more sense to log to a file than to a table 
in that case.

Emmanuel

-- 
Emmanuel Cecchet
Aster Data Systems
Web: http://www.asterdata.com



pgsql-hackers by date:

Previous
From: Bill Moran
Date:
Subject: Re: Going, going, GUCs!
Next
From: Andrew Dunstan
Date:
Subject: Re: Going, going, GUCs!