Add a check if an update/delete query has a RETURNING clause. If it does, use db.Queryx() instead of db.Exec() to return the appropriate rows
This problem stems from the client having to use Exec() when no return value is expected (to get the number of rows affected by the update/delete), and Queryx() (to get the result of a RETURNING clause) when we expect rows to be returned. There is no clean way to differentiate the two cases to my knowledge, because (1) we have no way of accurately determining if a delete/update query will return any rows before running it, and (2) we cannot run both Exec() and Queryx() one after another because we cannot assume the updates/deletes are idempotent.
I recognize that this approach seems hacky, and is not 100% accurate (eg. it fails when a column is named "returning"). However, it seems to be the best way to me to tackle this issue. I appreciate any other insights regarding this.
RETURNINGclause. If it does, usedb.Queryx()instead ofdb.Exec()to return the appropriate rowsThis problem stems from the client having to use
Exec()when no return value is expected (to get the number of rows affected by the update/delete), andQueryx()(to get the result of aRETURNINGclause) when we expect rows to be returned. There is no clean way to differentiate the two cases to my knowledge, because (1) we have no way of accurately determining if a delete/update query will return any rows before running it, and (2) we cannot run bothExec()andQueryx()one after another because we cannot assume the updates/deletes are idempotent.I recognize that this approach seems hacky, and is not 100% accurate (eg. it fails when a column is named "returning"). However, it seems to be the best way to me to tackle this issue. I appreciate any other insights regarding this.
Fixes #553