Re: Transaction aborts on syntax error.

From: "Zeugswetter Andreas SB SD" <ZeugswetterA(at)spardat(dot)at>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <simon(at)2ndquadrant(dot)com>, "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>, "Andrej Czapszys" <czapszys(at)comcast(dot)net>, "Gavin Sherry" <swm(at)linuxworld(dot)com(dot)au>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Transaction aborts on syntax error.
Date: 2004-02-13 16:42:36
Message-ID: 46C15C39FEB2C44BA555E356FBCD6FA49620B3@m0114.s-mxs.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message markw 2004-02-13 16:52:05 Re: Proposed Query Planner TODO items
Previous Message Stephan Szabo 2004-02-13 16:08:41 Re: 7.4 - FK constraint performance