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

Reply via email to