| From: | Jim Nasby <jim(at)nasby(dot)net> |
|---|---|
| To: | Peter Geoghegan <pg(at)heroku(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
| Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Subject: | Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE |
| Date: | 2014-01-11 00:09:02 |
| Message-ID: | 52D08B9E.6090005@nasby.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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(at)nasby(dot)net
512.569.9461 (cell) http://jim.nasby.net
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jim Nasby | 2014-01-11 00:14:46 | Re: Add CREATE support to event triggers |
| Previous Message | Jim Nasby | 2014-01-11 00:06:29 | Re: Disallow arrays with non-standard lower bounds |