zeroshade commented on issue #64: URL: https://github.com/apache/arrow-adbc/issues/64#issuecomment-1215591703
> In general, my understanding of most APIs is that prepared statements aren't really set up to benefit concurrent execution, only repeated execution from a single logical chain of execution...so Go still stands out here as the odd one out To be fair, nothing in the Go docs guarantees one way or the other as far as viability in this regard. So I went and dug into the actual `database/sql` package code... It turns out that under the hood, the `database/sql` package locks the connection until you call close on the `Rows` object, indicating you don't need the result set anymore. If you attempt to execute a prepared statement a second time before you close the previous result set, it internally grabs a new connection from the pool and re-prepares itself on the new connection and executes there, allowing the existing result set to continue just fine. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@arrow.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
