zeroshade opened a new issue, #61: URL: https://github.com/apache/arrow-adbc/issues/61
Rather than the separate `Execute` / `GetStream` functions, it might be better to follow something similar to FlightSQL's interface or Go's `database/sql` API. Have two functions: * Execute a query without expecting a result set: `Execute(struct AdbcConnection*, const char*, struct AdbcResult*, struct AdbcError*)` where `AdbcResult` would contain an optional LastInsertedID and Number of Rows affected * Execute a query to retrieve a result set: `Query(struct AdbcConnection*, const char*, struct ArrowArrayStream*, struct AdbcError*)` where the `ArrowArrayStream` is populated with the result set. Corresponding methods would exist for a Statement just without the need for taking the `const char*` as it would already be prepared in the statement. Some benefits of this idea: * With the interface enforcing the idea of the query -> retrieving the results being a single API call it makes concurrency easier to handle (any complexity would be handled by the driver implementation) by consumers of the interface. * Drivers can be aware of whether or not a user is expecting a result set and can operate accordingly. They don't have to interrogate the backend to know whether or not a result set is available or if the query was an update/insert vs a select. -- 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.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org