Re: INSERT ... ON CONFLICT UPDATE/IGNORE 4.0

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: INSERT ... ON CONFLICT UPDATE/IGNORE 4.0
Дата
Msg-id CA+TgmoYQ185bf=_Z5r0MWRbN2xLgPNMK4N-Q9aAPOC7coZ4HZA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: INSERT ... ON CONFLICT UPDATE/IGNORE 4.0  (Andres Freund <andres@anarazel.de>)
Ответы Re: INSERT ... ON CONFLICT UPDATE/IGNORE 4.0  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
On Fri, May 1, 2015 at 9:58 AM, Andres Freund <andres@anarazel.de> wrote:
> Right now this, besides cleanup, docs and syntax leaves only one real
> issue I know of. Which is the question what EXCLUDED actually refers to.
>
> Consider a table
> blarg(key int primary key, data text); with a BEFORE INSERT
> trigger that modifies 'data'. For the statement
>
> INSERT INTO blarg(key, data) VALUES(1, 'whatever')
> ON CONFLICT (key) DO UPDATE SET data = EXCLUDED.data;
>
> 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.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: initdb -S and tablespaces
Следующее
От: Andres Freund
Дата:
Сообщение: Re: INSERT ... ON CONFLICT UPDATE/IGNORE 4.0