Re: MERGE Specification
От | Marko Kreen |
---|---|
Тема | Re: MERGE Specification |
Дата | |
Msg-id | e51f66da0804280157j5491eec0rd59ee57540b3ed52@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: MERGE Specification (Robert Treat <xzilla@users.sourceforge.net>) |
Ответы |
Re: MERGE Specification
|
Список | pgsql-hackers |
On 4/25/08, Robert Treat <xzilla@users.sourceforge.net> wrote: > On Thursday 24 April 2008 23:40, Tom Lane wrote: > > Robert Treat <xzilla@users.sourceforge.net> writes: > > > Perhaps a better option would be to implement Merge per spec, and then > > > implement a "replace into" command for the oltp scenario. This way you > > > keep the spec behavior for the spec syntax, and have a clearly non-spec > > > command for non-spec behavior. > > > > In that case, it's a fair question to ask just who will use the "spec" > > syntax. As far as I can tell from years of watching the mailing lists, > > there is plenty of demand for a concurrent-safe insert-or-update > > behavior, and *exactly zero* demand for the other. I challenge you to > > find even one request for the "spec" behavior in the mailing list > > archives. (Simon doesn't count.) > > > > > AIUI the current implementation is designed to avoid race conditions partially > at the cost of being insert friendly and somewhat update unfriendly. My guess > is that most of the people wanting this for OLTP use want an update friendly > implementation (that's certainly been the majority of cases I've needed > myself, and that I have seen others use). This seems to hint that there should be 2 variants of merge/upsert - insert-friendly and update-friendly... It seems unlikely one implementation can be both. And especially bad would be implementation that is neither. -- marko
В списке pgsql-hackers по дате отправления: