From: | Peter Geoghegan <pg(at)heroku(dot)com> |
---|---|
To: | Marko Tiikkaja <marko(at)joh(dot)to> |
Cc: | rwestlun(at)gmail(dot)com, pgsql-bugs <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: BUG #13886: When INSERT ON CONFLICT DO UPDATE updates, it returns INSERT rather than UPDATE |
Date: | 2016-01-25 19:35:17 |
Message-ID: | CAM3SWZRs2yeYX6SFuDveUKTLZWQFm4j0ViwZRLtYvRyUvMrDNw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Mon, Jan 25, 2016 at 2:00 AM, Marko Tiikkaja <marko(at)joh(dot)to> wrote:
> FWIW, I would've expected to be able to do RETURNING excluded.foo which
> would have been NULL in case of INSERT, and the value from the updated tuple
> otherwise. But that doesn't seem to work.
The problem with that approach is that it makes both the target table
and the excluded pseudo table visible from within RETURNING. If we
were to do that, virtually every use of INSERT with both an ON
CONFLICT DO UPDATE clause and a RETURNING clause breaks. That's
because any unqualified column reference becomes ambiguous ("Did you
mean target.foo or excluded.foo?").
I was against doing this during the development of ON CONFLICT DO
UPDATE, because it would have introduced a surprising inconsistency
between INSERT statements (that use RETURNING) with and without the
new clause. Compatibility with 9.5 certainly seals that decision now.
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Marko Tiikkaja | 2016-01-25 19:46:47 | Re: BUG #13886: When INSERT ON CONFLICT DO UPDATE updates, it returns INSERT rather than UPDATE |
Previous Message | Peter Geoghegan | 2016-01-25 19:22:49 | Re: BUG #13886: When INSERT ON CONFLICT DO UPDATE updates, it returns INSERT rather than UPDATE |