On 2015-05-01 10:21:27 -0400, Robert Haas wrote:
> On Fri, May 1, 2015 at 10:10 AM, Andres Freund <andres@anarazel.de> wrote:
> > On 2015-05-01 10:06:42 -0400, Robert Haas wrote:
> >> On Fri, May 1, 2015 at 9:58 AM, Andres Freund <andres@anarazel.de> wrote:
> >> > would you rather have EXCLUDED.data refer to the tuple version from
> >> > VALUES (or a SELECT or ...) or to version from the BEFORE trigger?
> >>
> >> I think it would be completely shocking if it didn't refer to the
> >> version returned by the BEFORE trigger. My interpretation of the
> >> semantics of BEFORE triggers is that, once the trigger has fired and
> >> returned a new tuple, things should proceed just as if that new tuple
> >> were the one originally provided by the user.
> >
> > Well, it's a BEFORE INSERT trigger, not a BEFORE UPDATE, that's why I'm
> > not so sure that argument applies.
>
> Would the BEFORE UPDATE trigger even fire in this case?
BEFORE UPDATE triggers fire for INSERT ... ON CONFLICT UPDATE iff
there's a conflict, yes.
> The thing is, suppose somebody puts a BEFORE INSERT trigger and a
> BEFORE UPDATE trigger on the table, and each of those triggers does
> this:
>
> NEW.last_updated_time = clock_timestamp();
> return NEW;
>
> That should work, and should cover all cases, even if you're using UPSERT.
The BEFORE UPDATE would catch things in this case.
Greetings,
Andres Freund