This is a good idea, and it's fair. If you want me to hear/watch a sales pitch then it makes sense that I get something up front for the time spent. The only problem that I see is that it's not going to attract people who actually have money to spend. They've got better ways to make money then get paid to watch advertisments.
A transaction commit happens after the logic of the transaction is processed, and two or more parallell threads can start off with the same DB snapshot when processing their transactions. Supposing that one thread commits first, then the logic that the other one used in its processing will be invalid upon its turn to commit. I don't see how an UPSERT implementation would fix this. The solution arrived at by PostgreSQL is basically perfect.
Your answer is naive and wrong. See this Stack Overflow page. The solutions on this page work but none of them have the elegance of the newly available INSERT... ON DUPLICATE UPDATE method.
This is great. I've been using PosgreSQL for a while now. It's one of those pieces of software that just does what it's told and doesn't let you down. While I'm saying this there are credible rumours to the effect that the Oracle merge operation is broken.
Read the comments to the most upvoted answer at this stack exchange question. The final comment is:
Not reliably. I ended up with retry loops in the client code.:( – Randy Magruder Aug 27 '15 at 16:05
This makes me think that Bruce Momijan may have been thinking about Oracle's implementation of merge when he said that other implementations were handled very badly.
Slashdot Mirror
This is a good idea, and it's fair. If you want me to hear/watch a sales pitch then it makes sense that I get something up front for the time spent. The only problem that I see is that it's not going to attract people who actually have money to spend. They've got better ways to make money then get paid to watch advertisments.
This doesn't sound any better than the already available retry loop.....
A transaction commit happens after the logic of the transaction is processed, and two or more parallell threads can start off with the same DB snapshot when processing their transactions. Supposing that one thread commits first, then the logic that the other one used in its processing will be invalid upon its turn to commit. I don't see how an UPSERT implementation would fix this. The solution arrived at by PostgreSQL is basically perfect.
Your answer is naive and wrong. See this Stack Overflow page. The solutions on this page work but none of them have the elegance of the newly available INSERT ... ON DUPLICATE UPDATE method.
This is great. I've been using PosgreSQL for a while now. It's one of those pieces of software that just does what it's told and doesn't let you down. While I'm saying this there are credible rumours to the effect that the Oracle merge operation is broken. Read the comments to the most upvoted answer at this stack exchange question. The final comment is: :( – Randy Magruder Aug 27 '15 at 16:05
Not reliably. I ended up with retry loops in the client code.
This makes me think that Bruce Momijan may have been thinking about Oracle's implementation of merge when he said that other implementations were handled very badly.