From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Geoghegan <pg@bowt.ie>
cc: Andreas Joseph Krogh <andreas@visena.com>, pgsql-sql@postgresql.org
Subject: Re: Unable to use INSERT ... RETURNING with column from other table
In-reply-to: 
 <CAH2-Wz=egG5KCku7h4AHMYiLv_ht4b5D7o=GVaHRof54Eop+MA@mail.gmail.com>
References: 
 <CAH2-Wzm4Qss48XbhWEDuLTcnFCi7QzKWtiNwYBk1LurcC9CdKQ@mail.gmail.com>
 <VisenaEmail.5e.f9aed09bf35804e1.15f509189ac@tc7-visena>
 <CAH2-Wz=egG5KCku7h4AHMYiLv_ht4b5D7o=GVaHRof54Eop+MA@mail.gmail.com>
Comments: In-reply-to Peter Geoghegan <pg@bowt.ie>
	message dated "Tue, 24 Oct 2017 19:45:13 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <15479.1508900684.1@sss.pgh.pa.us>
Date: Tue, 24 Oct 2017 23:04:44 -0400
Message-ID: <15480.1508900684@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-sql-owner@postgresql.org

Peter Geoghegan <pg@bowt.ie> writes:
> As David says, you could use multiple CTEs for this.

Yeah.  The SELECT portion of the query, so far as the outer INSERT
is concerned, is just a black box that yields some column values to
be inserted.  We could wish that the INSERT's RETURNING clause
could examine additional column values that are available inside that
subquery, but I'm afraid that there are insurmountable semantic problems.
In particular, DISTINCT seems to break that entirely --- consider

insert into foo(id, name)
  select distinct 3, f.name
  from foo f
  where ...
returning id, f.id;

We can't just add "f.id" to the set of columns returned by the SELECT
part without changing the semantics of the DISTINCT.  Or if we ignore
that (acting like it was DISTINCT ON (3, f.name)) then we get an
underdetermined value of f.id, which doesn't seem appetizing either.

			regards, tom lane


-- 
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql