On Mon, Jan 25, 2016 at 11:46 AM, Marko Tiikkaja <marko@joh.to> wrote:
>> 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?").
>
>
> Surely there's a way to make this work so that EXCLUDED is a special tuple
> whose fields are normally not in scope, but can be accessed explicitly.
Perhaps, but that seems kind of invasive. I don't think that the
contents of EXCLUDED is necessarily interesting enough to be able to
project via RETURNING. There isn't that much new information to be
found in EXCLUDED.* in general. There are other details like that that
are also in general not visible from RETURNING, involving before
triggers, for example.
--
Peter Geoghegan