> 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.
Well, that's not even close to true, because of the rules about statements
within a multi-statement string getting merged into single transactions.
My meaning was that with appropriate begin/commit augmentation, the user should be able to achieve the same effects with multi-statement, and that Rule (a) makes this unachievable, at least in the case of NOTIFY.
My goal is to write a test case where the service being tested (which is a child process of the testing process) is known to be blocking in a PQexec call, and during this exact state the testing process disrupts the TCP connection between the service and postgres in various ways, to be sure that the service recovers.
I'm not sure how to know that PQexec() has entered and not yet returned in my service process other than to examine the effects of a partially complete PQexec() itself. If I can't use NOTIFY then perhaps I can sniff for the network traffic sent at the beginning of PQexec(), or perhaps there is some extra libpq logging I could enable to know that PQexec() is in process?
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?
-John
