Yugo NAGATA <nagata@sraoss.co.jp> writes: > I've looked at the commited fix. What I wonder is whether a change in > IsInTransactionBlock() is necessary or not.
> In fact, the result of IsInTransactionBlock does not make senses at > all in pipe-line mode regardless to the fix. ANALYZE could commit all > previous commands in pipelining, and this may not be user expected > behaviour.
This seems pretty much isomorphic to the fact that CREATE DATABASE will commit preceding steps in the pipeline. That's not great, I admit; we'd not have designed it like that if we'd had complete understanding of the behavior at the beginning. But it's acted like that for a couple of decades now, so changing it seems far more likely to make people unhappy than happy. The same for ANALYZE in a pipeline.
I agreed to leaving the description of CREATE DATABASE simplified by not introducing the idea of implicit transactions or, equivalently, "autocommit".
Just tossing out there that we should acknowledge that our wording in the BEGIN Reference should remain status quo based upon the same reasoning.
"By default (without BEGIN), PostgreSQL executes transactions in “autocommit” mode, that is, each statement is executed in its own transaction and a commit is implicitly performed at the end of the statement (if execution was successful, otherwise a rollback is done)."
"By default (without BEGIN), PostgreSQL creates transactions based upon the underlying messages passed between the client and server. Typically this means each statement ends up having its own transaction. In any case, statements that must not execute in a transaction (like CREATE DATABASE) must use the default, and will always cause a commit or rollback to happen upon completion."
It feels a bit out-of-place, maybe if the content scope is acceptable we can work it better into the Tutorial-Advanced Features-Transaction section and just replace the existing sentence with a link to there?
