Add rows_*() verbs

[mgirlich]

Closes #736.

returning: This argument is still experimental and not (yet?) in the generic. To support tidyselect and not trigger a warning by rlang::check_dots_used() (in the generic) the user has to quote it manually (see tidyverse/dplyr#5985). (Edit: not necessary anymore after check_dots_used() was removed in the generic).
Theoretically, one could execute arbitrary SQL in the RETURNING clause but I'm not sure whether there are sufficient use cases to support this.

nonexistent: The current implementation is nonexistent = "ignore". To support nonexistent = "error" one could use a foreign key constraint on y. I'll tackle this in another PR. (Update: renamed to unmatched and "error" is not supported for now)

rows_upsert(): This is the most tricky and needs different methods:

• Some databases (e.g. Oracle or MS SQL) support MERGE INTO ... WHEN (NOT) MATCHED
• Some databases (e.g. SQLite, Postgres) have an upsert if there is a unique constraint, basically INSERT ... ON CONFLICT DO UPDATE/NOTHING
• If there is no unique constraint this can still be done in one query with a CTE (e.g. Postgres) or two queries (e.g. SQLite)

It might make sense to add an argument so that the user can choose whether a unique constraint exists or not. See
cynkra/dm#616 (comment) for some more information on the Pros/Cons. I will do this in another PR.

[krlmlr]

Are we keeping the returning argument, or do we introduce new rows_*_returning() functions?

I saw that the default for in_place has changed to FALSE, I guess this means we no longer give a message if in_place is omitted?

Regarding integration with dm, I think we can release dbplyr first and then adapt dm -- the dbplyr update doesn't break dm's tests, because the latter still overwrites the methods. Should dbplyr give a warning mentioning that the rows_*() API behaves differently when dm <= 0.2.8 is loaded?

It looks like the SQL Server implementation needs more work, I'll propose something today. Postgres looks fine.

[krlmlr]

MSSQL seems good now.

[mgirlich]

Are we keeping the returning argument, or do we introduce new rows_*_returning() functions?

I'm okay with both. Do you have a preference?

I saw that the default for in_place has changed to FALSE, I guess this means we no longer give a message if in_place is omitted?

Yes, I don't see a need to give a message.

Regarding integration with dm, I think we can release dbplyr first and then adapt dm -- the dbplyr update doesn't break dm's tests, because the latter still overwrites the methods. Should dbplyr give a warning mentioning that the rows_*() API behaves differently when dm <= 0.2.8 is loaded?

Feel free to add a message though it will probably affect only few users.

MSSQL seems good now.

Thanks!

[krlmlr]

Thanks! Looks good to me, with cynkra/dm#988 we get the new behavior also for the legacy code in dm. I can release dm before or shortly after dbplyr, doesn't really matter.

[krlmlr]

So, let's keep the returning argument and avoid adding new messages.