Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> On 3/3/18 00:48, Tom Lane wrote:
>> I don't think that can possibly work. It would only be safe if, between
>> the thrower and the catcher, there were no other levels of control
>> operating according to the normal error-handling rules. But input
>> functions certainly cannot assume that they are only called by COPY,
>> so how could they safely throw a "soft error"?
> That assumes that throwing a soft error in a context that does not
> handle it specially is not safe. I'd imagine in such situations the
> soft error just behaves like a normal exception.
My point is that neither the thrower of the error, nor the catcher of it,
can possibly guarantee that there were no levels of control in between
that were expecting their resource leakages to be cleaned up by normal
error recovery. As a counterexample consider the chain of control
COPY -> domain_in -> SQL function in CHECK -> int4in
If int4in throws a "soft" error, and COPY catches it and skips
error cleanup, we've likely got problems, depending on what the SQL
function did. This could even break domain_in, although probably any
such effort would've taken care to harden domain_in against the issue.
But the possibility of SQL or PL functions having done nearly-arbitrary
things in between means that most of the backend is at hazard.
You could imagine making something like this work, but it's gonna take
very invasive and bug-inducing changes to our error cleanup rules,
affecting a ton of places that have no connection to the goal.
regards, tom lane
