Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE
От | Jim Nasby |
---|---|
Тема | Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE |
Дата | |
Msg-id | 52D08B9E.6090005@nasby.net обсуждение исходный текст |
Ответ на | Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE (Peter Geoghegan <pg@heroku.com>) |
Ответы |
Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE
|
Список | pgsql-hackers |
On 1/10/14, 4:40 PM, Peter Geoghegan wrote: > My problem is that in general I'm not sold on the actual utility of > making this kind of row locking work with exclusion constraints. I'm > sincerely having a hard time thinking of a practical use-case > (although, as I've said, I want to make it work with IGNORE). Even if > you work all this row locking stuff out, and the spill-to-disk aspect > out, the interface is still wrong, because you need to figure out a > way to project more than one reject per slot. Maybe I lack imagination > around how to make that work, but there are a lot of "ifs" and "buts" > either way. Well, the usual example for exclusion constraints is resource scheduling (ie: scheduling what room a class will be held in).In that context is it hard to believe that you might want to MERGE a set of new classroom assignments in? -- Jim C. Nasby, Data Architect jim@nasby.net 512.569.9461 (cell) http://jim.nasby.net
В списке pgsql-hackers по дате отправления: