On 19 July 2015 at 11:30, Rafal Pietrak <rafal@ztk-rp.eu> wrote:
when I have to invent/introduce additional features/columns/attributes (like a key in addition to a sequence), which are not required by the design, but necessary for implementation) is a workaround (almost by definition).
I'm sorry that you feel defensive about this, and apologies for repeating myself, but the fact that the random key can be duplicated means it should not be used as a primary key, so using a sequence as a primary key is not a workaround, it's a correction to the design.
Notwithstanding that, the reason UPSERT is required is because it's possible that two competing transactions can end up fighting over an INSERT and the workarounds that are required are either highly complex or not 100% successful (eg http://www.depesz.com/2012/06/10/why-is-upsert-so-complicated/).
Conversely, the workaround in the above case (even if you don't want to change the primary key) is trivial - as you yourself described.