Peter Eisentraut <peter.eisentr...@2ndquadrant.com> writes:
> On 2/28/17 08:17, Tom Lane wrote:
>> 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.
> I think it's different because it's not a global setting, it's only a
> behavior you select explicitly when you start a transaction block.
Yeah, that's the same it-won't-affect-you-if-you-don't-use-it argument
that we heard for server-side autocommit-off. I don't buy it.
I can think of two reasons even without any caffeine:
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.
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.)
In short, you can't make fundamental changes in transactional behavior
without enormous breakage. That was the lesson we learned from the
autocommit fiasco and I do not believe that it's inapplicable here.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
