On Sat, Apr 25, 2015 at 12:35 PM, Peter Geoghegan <pg@heroku.com> wrote:
>>> > That
>>> > it has 'morphing' characteristics imo just makes it worse, rather than
>>> > better. Besides being confusing that it has different meanings, it's far
>>> > from inconceivable that somebody wants to return values from the
>>> > preexisting, new, and merged rows.
>>>
>>> This is how RETURNING works from UPDATEs in general.
>>
>> And there's been a patch (which unfortunately died because it's
>> implementation wasn't good), to allow referring to the other versions of
>> the tuple. It has been wished for numerous times.
>
> Well, if that patch is ever committed, then it won't be hard to get
> the behavior here too, since it is literally exactly the same code. I
> don't change anything about it, and that seems to be your problem.
I withdraw this remark. Even in a world where this patch is committed,
it still makes sense for the INSERT returning behavior to not be
altered (and to project only TARGET tuples even if they come from the
auxiliary UPDATE). The "join" is within the auxiliary UPDATE, not the
INSERT, and it should be no more possible to project intermediate
tuples (like EXCLUDED.*) from the INSERT's RETURNING than it is to
project CTE scan tuples from an INSERT ... RETURNING with a CTE.
--
Peter Geoghegan