Thomas Hallgren <[EMAIL PROTECTED]> writes:
> I don't understand this either. Why a subtransaction at all?
> Don't get me wrong. I fully understand that a subtransaction would make
> error recovery possible. What I try to say is that the kind of error
> recovery that needs a subtransaction is fairly, or perhaps even very, rare.
On what evidence do you base that claim? It's true there are no
existing Tcl or Perl functions that do error recovery from SPI
operations, because it doesn't work in existing releases. That does
not mean the demand is not there. We certainly got beat up on often
enough about the lack of error trapping in plpgsql.
> or I can write:
> Savepoint sp = myConn->setSavepoint("foo");
> try
> {
> // do something
> sp.commit();
> }
> catch(SQLException e)
> {
> sp.rollback();
> // Handle error and continue execution.
> }
[ shrug... ] If you intend to design pljava that way I can't stop you.
But I think it's a bogus design, because (a) it puts extra burden on the
function author who's already got enough things to worry about, and
(b) since you can't support arbitrary rollback patterns, you have to
contort the semantics of Savepoint objects with restrictions that are
both hard to design correctly and complicated to enforce.
I don't believe you should do language design on the basis of avoiding
a 25% overhead, especially not when there's every reason to think that
number can be reduced in future releases. I got it down from 50% to 25%
in one afternoon, doing nothing that seemed too risky for late beta.
I think there's plenty more that can be done there when we have more
time to work on it.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings
