Thanks for the thoughts David. I assume there is a regression test suite for postgres? In addition to documentation, can a test case be added that will ensure the present behavior remains unchanged until someone thinks about fixing it? This will serve as another reminder about the issue?
On Mon, Apr 20, 2020 at 1:27 PM John Muehlhausen <jgm@jgm.org> wrote:
> My perspective as a libpq user is that multi-statement PQexec() should have > the same effects as multiple PQexec() calls other than for the former > dropping the results of all but the most recent statement.
Still, even without considering my usage, I find it odd that this would not be considered a bug, for the reason in my first sentence above. The current behavior means that the user has to think about transactions "and something else" when reasoning about the effects of statements. I would vote to remove the "and something else" which would then remove the need to augment the current documentation. As it stands, at minimum, the documentation needs to warn the user that similar notify effects are unachievable in the multi-statement realm?
The deeper into the architecture the change the more resistant to change it should be. This is pretty low-level and the benefits don't seem that great. It is functional, and the usage pattern involved, multi-statement commands, is one that is actively discouraged - so from my perspective classifying this as a bug that the core team should fix is unappealing. If someone wants to offer up a feature enhancement patch for critique then we'll see.
