I was somewhat confused as to how this was runtime-independent when it didn't require the user to provide the tcp stream, but it appears that the answer is that if you use any runtime other than async-std, it will silently spawn the async-std executor in the background.
In that sense tokio-postgres is more runtime-independent as you can use it with any runtime by providing your own tcp stream (as your library does with async-std's tcp stream).
In my opinion, runtime-independency means running out of the box on any runtime. Of course anyone can provide runtime-relevant tcp stream to use tokio-postgres on specific runtime, but it's a little tedious and uncommon.
I think the solution of async-std is reasonable, and the performance is acceptable, as you can see this benchmark.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.