Re: [HACKERS] Statement-level rollback

From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> 1. The argument for this is mostly, if not entirely, "application
> compatibility".  But it won't succeed at providing that if every BEGIN has
> to be spelled differently than it would be on other DBMSes.
> Therefore there is going to be enormous pressure to allow enabling the
> feature through a GUC, or some other environment-level way, and as soon
> as we do that we've lost.

I thought so, too.  I believe people who want to migrate from other DBMSs would set the GUC in postgresql.conf, or with
ALTERDATABASE/USER just for applications which are difficult to modify.
 

> 2. The proposed feature would affect the internal operation of PL functions,
> so that those would need to become bulletproof against being invoked in
> either operating environment.  Likewise, all sorts of intermediate tools
> like connection poolers would no doubt be broken if they don't know about
> this and support both modes.  (We would have to start by fixing postgres_fdw
> and dblink, for instance.)

Yes, I'm going to modify the PL's behavior.  I'll also check the dblink and postgres_fdw as well.  In addition, I'll
havea quick look at the code of pgpool-II and pgBouncer to see how they depend on the transaction state.  I'll run the
regressiontests of contribs, pgpool-II and pgBouncer with default_transaction_rollback_scope set to 'statement'.
 

But I don't see how badly the statement-level rollback affects those features other than PL.  I think the only relevant
thingto those client-side programs is whether the transaction is still running, which is returned with ReadyForQuery.
Bothof statement-level rollback and the traditional behavior leave the transaction running when an SQL statement fails.
Server-side autocommit differs in that respect.
 

Regards
Takayuki Tsunakawa