Re: INSERT ... ON CONFLICT UPDATE/IGNORE 4.0
От | Robert Haas |
---|---|
Тема | Re: INSERT ... ON CONFLICT UPDATE/IGNORE 4.0 |
Дата | |
Msg-id | CA+TgmoZ_X1D_S84aKc-_g6+wU5ri9Q-XYRe6yAMvuwe8wkuwCg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: INSERT ... ON CONFLICT UPDATE/IGNORE 4.0 (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: INSERT ... ON CONFLICT UPDATE/IGNORE 4.0
|
Список | pgsql-hackers |
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? 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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: