Tobias Schieferdecker

Yes, but I am not certain which behavior you'd like. If you use `count()` on a PK in a `dm_keyed_tbl` it will be kept as a PK: ``` r library(conflicted)...

So the idea is to artificially create a compound key? What if we instead just use (`returning`) all columns of the inserted rows with rows_append to match the rows of...

> Thought about that. Returning everything() can be unnecessarily expensive, e.g., in the presence of BLOB columns. Good point, and if we excluded BLOB columns we run into the original...

As for the user-facing side: Would a new function `dm_add_uk()` be alright with you?

Also: if there is no UK defined and there is an AI PK, should we do `dm_rows_append()` the way it was and issue a warning?

ETA possibly in a week?

True, but the user could always proactively add the row id col themselves and specify it as a unique key.

1. I am not sure if that will work with such a function, since if we remove key columns before the flattening, the flattening can't take place, and afterwards, we...

It works with SQL Server

I need to apologize, the issue description was a bit misleading: When creating a reprex I realized that the culprit was the argument `copy = FALSE`: ``` r library(tibble) con_pg