From: Andres Freund <andres@anarazel.de>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Peter Geoghegan <pg@heroku.com>
Cc: hlinnaka <hlinnaka@iki.fi>
Cc: Jeff Janes <jeff.janes@gmail.com>
Cc: Stephen Frost <sfrost@snowman.net>
Cc: Dean Rasheed <dean.a.rasheed@gmail.com>
Cc: Bruce Momjian <bruce@momjian.us>
Cc: Pg Hackers <pgsql-hackers@postgresql.org>
Subject: Re: INSERT ... ON CONFLICT UPDATE/IGNORE 4.0
Date: Fri, 1 May 2015 16:24:03 +0200
Message-ID: <20150501142403.GG22649@awork2.anarazel.de> (raw)
In-Reply-To: <CA+TgmoZ_X1D_S84aKc-_g6+wU5ri9Q-XYRe6yAMvuwe8wkuwCg@mail.gmail.com>
References: <CAM3SWZTGE0z5_E8wRi9wt3qgOiMpSwtwr5uDcZDGhRZ1_pz6vg@mail.gmail.com>
<20150501135800.GC22649@awork2.anarazel.de>
<CA+TgmoYQ185bf=_Z5r0MWRbN2xLgPNMK4N-Q9aAPOC7coZ4HZA@mail.gmail.com>
<20150501141052.GE22649@awork2.anarazel.de>
<CA+TgmoZ_X1D_S84aKc-_g6+wU5ri9Q-XYRe6yAMvuwe8wkuwCg@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-admin@postgresql.org
Cc: andres@anarazel.de, robertmhaas@gmail.com, pg@heroku.com, hlinnaka@iki.fi, jeff.janes@gmail.com, sfrost@snowman.net, dean.a.rasheed@gmail.com, bruce@momjian.us, pgsql-hackers@postgresql.org
Subject: Re: INSERT ... ON CONFLICT UPDATE/IGNORE 4.0
In-Reply-To: <20150501142403.GG22649@awork2.anarazel.de>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox