| From: | Peter Geoghegan <pg(at)heroku(dot)com> |
|---|---|
| To: | Marti Raudsepp <marti(at)juffo(dot)org> |
| Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Josh Berkus <josh(at)agliodbs(dot)com>, Kevin Grittner <kgrittn(at)ymail(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Craig Ringer <craig(at)2ndquadrant(dot)com> |
| Subject: | Re: INSERT ... ON CONFLICT {UPDATE | IGNORE} |
| Date: | 2014-10-08 09:28:46 |
| Message-ID: | CAM3SWZSXRjV_i5Zx3wWq3W7LSp5X09RE_ZYZH5V9TAUu7aCwzA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Oct 8, 2014 at 1:36 AM, Marti Raudsepp <marti(at)juffo(dot)org> wrote:
> I think there's a subtle difference in expectations too. The current
> BEFORE INSERT trigger behavior is somewhat defensible with an
> INSERT-driven syntax (though I don't like it even now [1]).
There is no way around it. We need to fire before row triggers to know
what to insert on the one hand, but on the other hand (in general) we
have zero ability to nullify the effects (or side-effects) of before
triggers, since they may execute arbitrary user-defined code. I think
there is a good case to be made for severely restricting what before
row triggers can do, but it's too late for that.
> But the
> MERGE syntax, to me, strongly implies that insertion doesn't begin
> before determining whether a conflict exists or not.
I think you're right. Another strike against the MERGE syntax, then,
since as I said we cannot even know what to check prior to having
before row insert triggers fire.
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Marti Raudsepp | 2014-10-08 09:33:25 | Re: INSERT ... ON CONFLICT {UPDATE | IGNORE} |
| Previous Message | Peter Geoghegan | 2014-10-08 09:22:54 | Re: Promise index tuples for UPSERT |