
> In both cases, the transaction either commits or rollback occurs. No
> other option is possible at the end of the transaction, but in the first
> style of transaction semantics you get a "mid-way" decision point. This
> only refers to retryable errors, since errors like access rights
> violations and many other system errors aren't retryable. In the example

You seem to ignore the fact, that a lot of errors (and I assume most of 
the real world cases, where the appl actually reacts inside a transaction) are 
"repared" by these applications by doing something else instead.

Like the application does an insert gets a duplicate key error and does an update 
instead. Or it does an insert gets a foreign key constraint violation,
populates the foreign table and does the insert again. Note that this programming 
practice is more efficient, than letting the appl check beforehand if the error cases 
are seldom.

It seems to me, that leaving all this to the client (which implicitly inserts 
savepoints) can never be as efficient as a serverside feature.

Andreas

Fri, 13 Feb 2004 14:36:50 +0100
"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at>
Re: Transaction aborts on syntax error.
"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at> writes:
> It seems to me, that leaving all this to the client (which implicitly
> inserts savepoints) can never be as efficient as a serverside feature.

I think this is an overly narrow view of "efficiency".  With client
control, the client can insert savepoints whereever it needs them,
which might not be for every statement.  Savepoints that you don't
actually need are going to be a fairly expensive overhead, AFAICS.

Also, in the V3 protocol, sending along extra BEGIN and COMMIT commands
doesn't have to cost you any extra network round trips.

			regards, tom lane

Fri, 13 Feb 2004 09:50:08 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: Transaction aborts on syntax error. 
Can we clarify what is meant by the client?  It is my
expectation/desire that the client library would handle this as a
setting similar to "AutoCommit", which would implicitly protect each
statement within a nested block (savepoint), causing only itself to
abort.  Such as, "OnError=>[abort|continue]", abort being the default.

Performance considerations are currently secondary to the fact that
the transaction abort problem can only be solved by nested
transactions.  In their current state transactions are not
convinient/practical (for me).

-ESR-

tgl@sss.pgh.pa.us (Tom Lane) wrote in message news:<2098.1076683808@sss.pgh.pa.us>...
> "Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at> writes:
> > It seems to me, that leaving all this to the client (which implicitly
> > inserts savepoints) can never be as efficient as a serverside feature.
> 
> I think this is an overly narrow view of "efficiency".  With client
> control, the client can insert savepoints whereever it needs them,
> which might not be for every statement.  Savepoints that you don't
> actually need are going to be a fairly expensive overhead, AFAICS.
> 
> Also, in the V3 protocol, sending along extra BEGIN and COMMIT commands
> doesn't have to cost you any extra network round trips.
> 
> 			regards, tom lane
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if your
>       joining column's datatypes do not match

13 Feb 2004 14:15:30 -0800
ramirez@idconcepts.org (Edwin S. Ramirez)
Re: Transaction aborts on syntax error.