
> > 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,

Yes, but not if the client API does implicit savepoints. So imho if it is not 
cheap we should not start to supply API's that do them implicitly.

> which might not be for every statement.  Savepoints that you don't
> actually need are going to be a fairly expensive overhead, AFAICS.

Well with other db's per statement rollback is a no overhead feature, 
so this is pg specific. (In the sense of: nothing is done that would not need 
to be done anyway, since they all undo the changes)

Imho the 80% main use case for applications would be for "duplicate key" 
to not abort. For interactive psql it would probably be the syntax error.  
Maybe something can be done about those special cases to make partial 
rollback cheaper for those.

Andreas

Fri, 13 Feb 2004 17:42:36 +0100
"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at>
Re: Transaction aborts on syntax error.
"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at> writes:
>> which might not be for every statement.  Savepoints that you don't
>> actually need are going to be a fairly expensive overhead, AFAICS.

> Well with other db's per statement rollback is a no overhead feature, 
> so this is pg specific.

I very much doubt that.  We are not expending any disk I/O to do
rollback, which is not true in (say) Oracle.  I'm concerned about the
internal bookkeeping overhead.

			regards, tom lane

Fri, 13 Feb 2004 16:31:45 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: Transaction aborts on syntax error. 