zeroshade commented on issue #64: URL: https://github.com/apache/arrow-adbc/issues/64#issuecomment-1215277102
> An individual statement can be used multiple times, but result sets cannot be read concurrently (that is: executing a statement invalidates prior result sets) Are we referring to result sets from *different queries* or only putting a limitation on result sets from a single prepared statement? Go's Query returns a `Rows` object which is then used to iterate over the results, but there's no requirement on *when* that iteration can happen. To guarantee safety we'd have to buffer the entire result set into memory to ensure that they don't get invalidated by a subsequent query, which would be extremely undesireable. This would also technically be true for the proposed ADBC API which just populates the `ArrowArrayStream*` and let's the consumer decide how/when to iterate that stream and release it. This seems like an extraordinarily painful requirement. > Prepared statements follow regular statements in behavior. (This makes Golang support a little weird; Golang is exceptional in allowing concurrent use of prepared statements) So I looked at the docs again, and as per my comment [here](https://github.com/apache/arrow-adbc/issues/64#issuecomment-1214417469) I was wrong. While the prepared statement can be used by multiple goroutines, it will not be used concurrently by those goroutines. Basically the `database/sql` package's `sql.Stmt` object is safe for concurrent use, but it internally ensures serialization to it's calls to the underlying Driver's `driver.Stmt` object. It is, however, bound to a single Connection object. -- 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