On 2015-05-01 10:21:27 -0400, Robert Haas wrote: > On Fri, May 1, 2015 at 10:10 AM, Andres Freund <and...@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 <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
