Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AdbcStatementExecuteUpdate/AdbcStatementExecuteQuery & rows_affected #79

Closed
Tracked by #76
hannes opened this issue Aug 26, 2022 · 3 comments · Fixed by #95
Closed
Tracked by #76

AdbcStatementExecuteUpdate/AdbcStatementExecuteQuery & rows_affected #79

hannes opened this issue Aug 26, 2022 · 3 comments · Fixed by #95

Comments

@hannes
Copy link

hannes commented Aug 26, 2022

AdbcStatementExecuteUpdate can set rows_affected, which is a bit ancient given that most SQL systems support the RETURNING clause now, which makes the separation between ExecuteQuery and ExecuteUpdate redundant. I propose to have only one method to run a query, possibly along with allowing the out to be nullptr in AdbcStatementExecuteQuery. rows_affected should be removed.

@hannes
Copy link
Author

hannes commented Aug 26, 2022

@lidavidm
Copy link
Member

Whoops, I didn't see this this morning. Folding Query/Update together sounds reasonable, leaving Partition separate. (Sorry for the churn.)

The explicit rows_affected, parameter, though, helps when trying to adapt to things like Python's DBAPI and Go's database/sql (as @zeroshade pointed out). So I don't think it hurts to have it, even if support might be a mixed bag.

@lidavidm lidavidm mentioned this issue Aug 26, 2022
12 tasks
@lidavidm lidavidm linked a pull request Aug 30, 2022 that will close this issue
@lidavidm
Copy link
Member

See #95

@lidavidm lidavidm added this to the 0.1.0 milestone Dec 1, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
No open projects
Development

Successfully merging a pull request may close this issue.

2 participants