2 ms·
> 1. Note that there are no plans for postgres to implement a specialised UPSERT. The plan was/is to implement MERGE, which is a fair bit more generic (especial
by the_mitsuhiko 13y ago
> 1. Note that there are no plans for postgres to implement a specialised UPSERT. The plan was/is to implement MERGE, which is a fair bit more generic (especially with the 2008 and 2011 extensions). In fact, TFA very specifically disagrees with this route in his conclusion.
Does the SQL standard actually guarantee that a MERGE is atomic? After all the MERGE statement involves a subselect which seems to be about as concurrency safe as a SQLite replace insert which a join.
- mjn 13y agoThe MERGE itself is atomic, but it doesn't prevent duplicate insertions without a lock: http://stackoverflow.com/questions/9871644/is-merge-an-atomic-statement-in-sql2008 http://stackoverflow.com/questions/9871644/is-merge-an-atomi...
- jeltz 13y agoIf PostgreSQL goes with an implementation of MERGE like that then it would not be a replacement for UPSERT. With UPSERT you can make sure to never get any constraint violations.