Re: MERGE vs REPLACE
От | Simon Riggs |
---|---|
Тема | Re: MERGE vs REPLACE |
Дата | |
Msg-id | 1132166072.4959.30.camel@localhost.localdomain обсуждение исходный текст |
Ответ на | Re: MERGE vs REPLACE (Martijn van Oosterhout <kleptog@svana.org>) |
Ответы |
Re: MERGE vs REPLACE
|
Список | pgsql-hackers |
On Wed, 2005-11-16 at 18:34 +0100, Martijn van Oosterhout wrote: > On Wed, Nov 16, 2005 at 11:37:46AM -0500, Bruce Momjian wrote: > > > > Interesting approach. Actually, we could tell the user they have to use > > BEGIN;LOCK tab before doing MERGE, and throw an error if we don't > > already have a table lock. > > The bit I'm still missing is why there needs to be a lock at all. The > SQL standard doesn't say anywhere that concurrent MERGE operations > can't conflict. It seems to me that standard visibility rules apply. If > neither MERGE statement can see the results of the other, then they > will both INSERT. If you don't have a UNIQUE constraint to prevent this > then what's the problem? > > It seems to me people would like, in the case of an existing UNIQUE > constraint, to be able to use it to prevent "duplicate key" errors. > This is nice, but the standard doesn't require that either. > > In other words, if we can use an index to avoid duplicate key errors, > fine. But if there is no index available, it is not an error to do an > INSERT because another INSERT was hidden from you. > > Conceptually, a MERGE statement is just a long string of INSERTs and > UPDATEs in the same transaction and I think we should treat it as > such. Agreed. Best Regards, Simon Riggs
В списке pgsql-hackers по дате отправления: