Re: [HACKERS] Statement-level rollback - Mailing list pgsql-hackers

From Tsunakawa, Takayuki
Subject Re: [HACKERS] Statement-level rollback
Date
Msg-id 0A3221C70F24FB45833433255569204D1F6A9D7F@G01JPEXMBYT05
Whole thread Raw
In response to Re: [HACKERS] Statement-level rollback  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
From: pgsql-hackers-owner@postgresql.org
> [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Tom Lane
> "Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com> writes:
> > As I stated here and at the PGConf.ASIA developer meeting last year,
> > I'd like to propose statement-level rollback feature.
> 
> I do not really see how this would ever get past the compatibility problems
> that forced us to give up on server-side autocommit years ago.

Could you tell me more about that problem?  What kind of incompatibility would this feature introduce?

> If you want to provide a client-side facility for this, perhaps that could
> fly.

Do you mean a feature of psqlODBC that implicitly issues SAVEPOINT and RELEASE SAVEPOINT for each SQL statement?  One
reasonI want to implement the feature is to avoid eliminate those round-trips for performance.  Or, do you mean a
client-sideconnection parameter like "rollback_scope={transaction | statement}?"  Yes, I'll implement it for major
clientdrivers so that the driver issues "SET SESSION CHARACTERISTICS FOR TRANSACTION ROLLBACK SCOPE {TRANSACTION |
STATEMENT}"upon connection.  psqlODBC has already a connection parameter, Protocol, for that purpose.
 

Regards
Takayuki Tsunakawa






pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [HACKERS] Time to drop old-style (V0) functions?
Next
From: Fabien COELHO
Date:
Subject: Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands:\quit_if, \quit_unless)