| From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
|---|---|
| To: | Peter Geoghegan <pg(at)heroku(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: INSERT...ON DUPLICATE KEY IGNORE |
| Date: | 2013-09-05 00:08:48 |
| Message-ID: | c0ddb74c-41d9-4dd5-9a3c-64a5f6f05dad@email.android.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
We seem to be miscommunication a bit.
You've proposed an framework and algorithm for something I'd really, really like to see. I don't think that it can work explicitly as you proposed, so I roughly sketched out a solution I can see.
I don't want "my" idea to win, I want a idea to win. I haven't fleshed out my idea to the point where I would consider it something ready to implement or something.
You're the patch author here whose plans are laid open to be scrutinized ;). If you think my idea has merit, use and adapt it to reality. If not, find another, better, solution.
Even if our path to that goal is confrontational at times, the goal is to find a good solution, not the argument itself.
I haven't argued about INSERT ... DUPLICATE LOCK because the page locking scheme doesn't seem to work out for plain DUPLICATE. No need to think/argue about the fancier version in that case.
Regards,
Andres
Please excuse brevity and formatting - I am writing this on my mobile phone.
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2013-09-05 00:47:22 | Re: INSERT...ON DUPLICATE KEY IGNORE |
| Previous Message | Peter Geoghegan | 2013-09-04 23:16:16 | Re: INSERT...ON DUPLICATE KEY IGNORE |