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
