Damir Belyalov <dam.be...@gmail.com> writes:
>> I don't think this is the right approach. Creating a subtransaction for
>> each row will cause substantial performance issues.
> Subtransactions aren't created for each row. The block of rows in one
> subtransaction is 1000 (SAFE_BUFFER_SIZE) and can be changed.
I think that at this point, any patch that involves adding subtransactions
to COPY is dead on arrival; whether it's batched or not is irrelevant.
(It's not like batching has no downsides.)
> InputFunctionCallSafe() is good for detecting errors from input-functions
> but there are such errors from NextCopyFrom () that can not be detected
> with InputFunctionCallSafe(), e.g. "wrong number of columns in row''.
If you want to deal with those, then there's more work to be done to make
those bits non-error-throwing. But there's a very finite amount of code
involved and no obvious reason why it couldn't be done. The major problem
here has always been the indefinite amount of code implicated by calling
datatype input functions, and we have now created a plausible answer to
that problem.
regards, tom lane
