Josh Berkus wrote: > Funny, we were just discussing this at OpenDBCon. Seems that you > can't do a full implementation of MERGE without Predicate Locking > (the ability to say "lock this table against inserts or updates of > any row with key=5"). However, Peter suggested that we could do a > proof-of-concept implementation, working out syntax and trigger > issues, based on a full table lock and do the hard work once it was > proved to be feasable.
Yes, I've started to work on this. Realizing that the current way to manually do an UPDATE-else-INSERT or DELETE-then-INSERT involves a table lock anyway, a MERGE implementation using a table lock would at least give some convenience benefit to users. (And possibly some performance, too, if the decision logic is currently run in the client.) A predicate locking implementation for MERGE might actually not be all that complicated, because you only need to look on pk = constant, not on arbitrary expressions. Nevertheless, I think it's best to write the MERGE command first and then optimize the locking. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org
