"David G. Johnston" <david.g.johnston@gmail.com> writes:
> As for your usage of "conn.setAutocommit(true)" - IIUC that is irrelevant
> to this entire discussion. You've chosen to bundle up multiple statements
> into a single Statement.execute(string) call which obeys the rules of the
> simple query protocol - multiple statements:
I doubt it. We closed the not-in-transaction-block loophole decades
ago for simple query protocol. What's at stake here is what happens
when a series of extended-protocol commands are given without Sync
between them, which we interpret as a request to run them all in the
same transaction. I'm a bit surprised that the JDBC driver is choosing
to issue them that way, because it implies (at least) that it's parsing
the string enough to break it down into separate SQL commands. But
we'd not be having this conversation if that weren't happening.
Anyway, that scenario *should* be subject to the same rules as multiple
statements in one simple-query message, only it wasn't up till now.
> Is there room for improved communication on the minor-release change in
> behavior? Probably.
Yeah, I wish I could have that release note back :-(. We don't really
have any mechanism for updating release notes after the fact. I could
go and fix it in the git repo, but nobody would see it until after the
next quarterly releases which seems a bit too late.
> As for discussing reverting this in the back-branches given new evidence
> and scenarios, that is possible and I've yet to go back and fully review
> that discussion thread in light of this new information.
I think there's zero chance we'd revert the bug fix at this point.
If we'd realized that the JDBC driver behaves this way, we might have
debated a little harder about whether this really had to be fixed in
the back branches --- but it's done now, and it is a bug fix.
regards, tom lane
