From: Tom Lane [mailto:t...@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 ALTER DATABASE/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 have a quick look at the code of pgpool-II and pgBouncer to see how they depend on the transaction state. I'll run the regression tests 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 thing to those client-side programs is whether the transaction is still running, which is returned with ReadyForQuery. Both of 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
