Tom,
Emmanuel Cecchet <m...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
