Re: Using results from INSERT ... RETURNING - Mailing list pgsql-hackers

From Jaime Casanova
Subject Re: Using results from INSERT ... RETURNING
Date
Msg-id 3073cc9b0907181812q1a6d33c4oce254603ae05bcef@mail.gmail.com
Whole thread Raw
In response to Re: Using results from INSERT ... RETURNING  (Merlin Moncure <mmoncure@gmail.com>)
Responses Re: Using results from INSERT ... RETURNING  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Sat, Jul 18, 2009 at 6:25 PM, Merlin Moncure<mmoncure@gmail.com> wrote:
> On Sat, Jul 18, 2009 at 5:21 PM, Jaime
> Casanova<jcasanov@systemguards.com.ec> wrote:
>> my questions first:
>> - what's the use case for this?
>
> Being able to use 'returning' in a subquery is probably the #1 most
> requested feature for postgresql (it's also a todo). Solving it for
> 'with' queries is a nice step in the right direction, and sidesteps
> some of the traps that result from the general case.

ah! that's why i asked: 'if we will support this, shouldn't we
supporting INSERT RETURNING inside subqueries too?'
i'm not too confident with the code but i think the problems for both
cases have to be similar so if we solve one, why not the other?

>
> move records from one table to another:
> with foo as (delete from bar where something returning *) insert
> insert into baz select foo.*:
>

seems like a corner case...

> gather defaulted values following an insert for later use:
> with foo as (insert into bar(field) select 'hello' from
> generate_series(1,n) returning *)  insert into baz select foo.*;
>

ok


--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387171157


pgsql-hackers by date:

Previous
From: Merlin Moncure
Date:
Subject: Re: Using results from INSERT ... RETURNING
Next
From: Andres Freund
Date:
Subject: Re: generic explain options v3 - RR Review