From: | Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec> |
---|---|
To: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
Cc: | Marko Tiikkaja <marko(dot)tiikkaja(at)cs(dot)helsinki(dot)fi>, PostgreSQL hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Using results from INSERT ... RETURNING |
Date: | 2009-07-19 01:12:39 |
Message-ID: | 3073cc9b0907181812q1a6d33c4oce254603ae05bcef@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Jul 18, 2009 at 6:25 PM, Merlin Moncure<mmoncure(at)gmail(dot)com> wrote:
> On Sat, Jul 18, 2009 at 5:21 PM, Jaime
> Casanova<jcasanov(at)systemguards(dot)com(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2009-07-19 01:15:38 | Re: generic explain options v3 - RR Review |
Previous Message | Merlin Moncure | 2009-07-18 23:25:20 | Re: Using results from INSERT ... RETURNING |