It's frustrating to see this now, after writing my review.
Hi Phil, please accept my apologies for the misunderstanding. I still think much of your comments were useful and many will end as improvements in the library.
I thought I was reviewing a library that, quoting your docs, made "ease of use" its first design goal and aimed to "hide the MySQL protocol complexities". Make up your mind, are you trying to hide the protocol or provide something close to it?
Ease of use is written there because it is really important to me. I've tried to hide as many complexities of the protocol as I've been able to, without compromising performance (maybe too many for a protocol library, as we'll discuss below). I've abstracted the handshake algorithm, the different encodings, and tried to expose an interface as simple as possible. But the library is not an ORM or a SQL framework, and the documentation may not be clear enough in scope. https://github.com/anarthal/mysql/issues/70 addresses this rewording.
You are explicitly blaming the protocol for this restriction in that quote. It seems that that is not true, and that it is a limitation of the library.
If I were writing my review again on the basis of this being a low-level protocol library - which I'm not going to do, I don't have time - I would probably say that support for this sort of pipelining is essential. I would perhaps hope to see "low-level" functions that encode and decode the protocol packets, which the user could even use with their own networking layer, if they wanted to.
I've raised https://github.com/anarthal/mysql/issues/76 to correct that wording, as it is definitely not true. This section should explain the whole story, with both the library limitation and the protocol capabilities. I've raised https://github.com/anarthal/mysql/issues/75 for pipeline mode. Regards, Ruben.