Re: INSERT ... ON CONFLICT DO UPDATE

On 19 July 2015 at 11:30, Rafal Pietrak <rafal(at)ztk-rp(dot)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.

Geoff