Re: MERGE Specification
От | Decibel! |
---|---|
Тема | Re: MERGE Specification |
Дата | |
Msg-id | 13D620EF-2805-47E9-A063-0849E6AF720E@decibel.org обсуждение исходный текст |
Ответ на | Re: MERGE Specification (Martijn van Oosterhout <kleptog@svana.org>) |
Ответы |
Re: MERGE Specification
|
Список | pgsql-hackers |
On Apr 22, 2008, at 3:20 PM, Martijn van Oosterhout wrote: > On Tue, Apr 22, 2008 at 02:19:24PM -0500, Decibel! wrote: >> But no matter how this is done, I think we need to handle the race >> conditions, and handle them by default. If people *really* know what >> they're doing, they can disable the row locking (perhaps one way to >> do this would be to grab an explicit lock on the table and have merge >> check for that...). > > I disagree. The spec doesn't require it and MERGE is useful without > it. > For a first cut I would say implement as the spec says, race > conditions > and all. Later we can think on whether it's worth handling them > directly. That really strikes me as taking the "MySQL route". If push comes to shove, I'll take a MERGE with race conditions over no merge at all, but I think it's very important that it does the right thing. Just because the spec doesn't say anything about it doesn't mean it's ok. -- Decibel!, aka Jim C. Nasby, Database Architect decibel@decibel.org Give your computer some brain candy! www.distributed.net Team #1828
В списке pgsql-hackers по дате отправления: