Skip site navigation (1) Skip section navigation (2)

Re: BUG #3320: Error when using INSERT...RETURNING as a subquery

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "David Fetter" <david(at)fetter(dot)org>
Cc: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Jan Szumiec" <jan(dot)szumie(at)infiniteloop(dot)eu>, <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #3320: Error when using INSERT...RETURNING as a subquery
Date: 2007-05-29 17:10:48
Message-ID: 87646bo8rr.fsf@oxford.xeocode.com (view raw or flat)
Thread:
Lists: pgsql-bugs
"David Fetter" <david(at)fetter(dot)org> writes:

> On Tue, May 29, 2007 at 09:41:38AM -0400, Tom Lane wrote:
>> "Jan Szumiec" <jan(dot)szumie(at)infiniteloop(dot)eu> writes:
>> > UPDATE items SET (type, post_id) = (INSERT INTO efforts (effort) VALUES
>> > (667) RETURNING 'Item', id) WHERE id = 1937
>> 
>> Sorry, RETURNING is only supported at the top level of a query.
>
> What would be involved with making this possible?  What we have at the
> moment is a pretty clear POLA violation because unlike the rest of the
> row-returning objects (tables, views, SRFs and VALUES() clauses), only
> RETURNING can't be used in a subquery.

It has the same problem that SELECT triggers have. How many rows should you
expect that subquery to insert, update, or delete if it's used in a join
clause? Or in the where clause of another insert/update/delete statement?

-- 
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com


In response to

Responses

pgsql-bugs by date

Next:From: Alceu PazDate: 2007-05-29 19:33:53
Subject: BUG #3321: No start service
Previous:From: David FetterDate: 2007-05-29 16:59:15
Subject: Re: BUG #3320: Error when using INSERT...RETURNING as a subquery

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group