Re: Error handling in plperl and pltcl

Richard Huxton <dev(at)archonet(dot)com> writes:
> Tom Lane wrote:
>> The real point here is that omitting the per-command subtransaction
>> ought to be a hidden optimization, not something that intrudes to the
>> point of having unclean semantics when we can't do it.

> Sorry to be stupid here, but I didn't understand this when it was
> disussed originally either. Why a subtransaction per command rather than
> one per function?

So that when the Tcl programmer writes "catch" around a SPI command,
or the Perl programmer writes "eval" around a SPI command, they see
sensible behavior. A reasonable person would expect to be able to use
the language's standard error-trapping constructs to trap any error
thrown by a SPI call and then continue processing (a la plpgsql
exception blocks). Before 8.0 it was impossible to support this
behavior, and what we actually did was, in effect, to seal off the Tcl
or Perl function so that it couldn't touch the database state --- after
the first SPI error all subsequent SPI operations would fail immediately
until control exited the Tcl or Perl function, whereupon the error would
be re-thrown. So you could try to trap an error but you couldn't do
anything useful after having done so, and you couldn't prevent it from
aborting the surrounding transaction.

I feel that behavior was obviously bogus and cannot be justified simply
on grounds of efficiency. A wise man once said "I can make this program
arbitrarily fast ... if it doesn't have to give the right answer";
I think that applies here. The semantics I want to see are that
catch/eval can trap errors and continue processing, and given the tools
we have at the moment that requires a subtransaction per SPI call. We
can think about ways to optimize this later, but I'm not putting up with
the broken semantics any longer than I have to.

In the case of Perl I suspect it is reasonably possible to determine
whether there is an "eval" surrounding the call or not, although we
might have to get more friendly with Perl's internal data structures
than a purist would like. In the case of Tcl I'm not sure this is
really going to be feasible :-(, because AFAICS the interpreter state
is encoded as a series of return addresses buried on the stack; and
even if you could detect the standard "catch" function you couldn't be
sure what other custom-built Tcl statements might have catch-like
functionality. But perhaps for Tcl we could think in terms of
optimizations like continuing one subtransaction across multiple SPI
commands as long as there's no failure. Jan also suggested the
possibility of replacing the standard "catch" command, which might be
good enough (though the prospect of nonstandard catch-like commands
worries me).

regards, tom lane