You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
AdbcStatementExecuteUpdate
can setrows_affected
, which is a bit ancient given that most SQL systems support theRETURNING
clause now, which makes the separation betweenExecuteQuery
andExecuteUpdate
redundant. I propose to have only one method to run a query, possibly along with allowing theout
to benullptr
inAdbcStatementExecuteQuery
.rows_affected
should be removed.The text was updated successfully, but these errors were encountered: