On Wed, Oct 8, 2014 at 12:28 PM, Peter Geoghegan <pg@heroku.com> wrote:
> On Wed, Oct 8, 2014 at 1:36 AM, Marti Raudsepp <marti@juffo.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.
With my proposal this problem disappears: if we prevent BEFORE
triggers from changing key attributes of NEW in the case of upsert,
then we can acquire value locks before firing any triggers (before
even constructing the whole tuple), and have a guarantee that the
value locks are still valid by the time we proceed with the actual
insert/update.
Other than changing NEW, the side effects of triggers are not relevant.
Now, there may very well be reasons why this is tricky to implement,
but I haven't heard any. Can you see any concrete reasons why this
won't work? I can take a shot at implementing this, if you're willing
to consider it.
> 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.
There are no users of new "upsert" syntax out there yet, so it's not
too late to rehash the semantics of that. This in no way affects users
of old INSERT/UPDATE syntax.
Regards,
Marti
