Knowing the way how postgres development usually works, they would never ship something that’s not working correctly, so their choices boil down to unbearably slow or really complicated and considering how their implementation continues to slip, they are aiming for correct AND fast.
I too think that the one sanctioned MERGE implementation should be universally useable. When you believe that you can cheat or that you don’t care about speed, then there are many useable workarounds available (and in use) today.
In my case, the one big use for merges would be an import job of which currently only ever one runs concurrently over the same data, so I can very easily do update followed by insert if zero rows were affected. Clearly totally within the “doesn’t needed to be correct, but needs to be fast” domain.
For me, http://www.depesz.com/2012/06/10/why-is-upsert-so-complicated/ provided a huge insight showing that for upserts, you basically have the choice between incorrect (race ridden), unbearably slow or really, really complicated.
Knowing the way how postgres development usually works, they would never ship something that’s not working correctly, so their choices boil down to unbearably slow or really complicated and considering how their implementation continues to slip, they are aiming for correct AND fast.
I too think that the one sanctioned MERGE implementation should be universally useable. When you believe that you can cheat or that you don’t care about speed, then there are many useable workarounds available (and in use) today.
In my case, the one big use for merges would be an import job of which currently only ever one runs concurrently over the same data, so I can very easily do update followed by insert if zero rows were affected. Clearly totally within the “doesn’t needed to be correct, but needs to be fast” domain.