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(at)sss(dot)pgh(dot)pa(dot)us (Tom Lane) wrote in message news:<2098(dot)1076683808(at)sss(dot)pgh(dot)pa(dot)us>...
> "Zeugswetter Andreas SB SD" <ZeugswetterA(at)spardat(dot)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