You can have INSERT ... SELECT RETURNING ... as a query in Postgres.
The RETURNING applies to the INSERT. See:
CREATE TABLE foo(i INT);
INSERT INTO foo(i) SELECT generate_series(1,5) RETURNING i;
Anyway, CTEs might work, but I can't see any good way to pass the
association through without th
On Tue, Apr 24, 2012 at 11:30 AM, David Fetter wrote:
> On Tue, Apr 24, 2012 at 08:12:10AM +1000, Chris Angelico wrote:
>> Of course, the question I never asked (never bothered to, really)
>> was: Is it really any better than simply doing the first insert and
>> retrieving the ID in my application
On Tue, Apr 24, 2012 at 08:12:10AM +1000, Chris Angelico wrote:
> On Tue, Apr 24, 2012 at 6:49 AM, Nick Apperson wrote:
> > There are obviously workarounds for this, but I'm wondering why
> > the following query shouldn't work. It seems like it should. With
> > MVCC already present on the back-end
On Tue, Apr 24, 2012 at 6:49 AM, Nick Apperson wrote:
> There are obviously workarounds for this, but I'm wondering why the
> following query shouldn't work. It seems like it should. With MVCC already
> present on the back-end, I can't see any reason other than additional
> parsing routines that t
On 23 April 2012 21:49, Nick Apperson wrote:
> There are obviously workarounds for this, but I'm wondering why the
> following query shouldn't work. It seems like it should. With MVCC already
> present on the back-end, I can't see any reason other than additional
> parsing routines that this could
There are obviously workarounds for this, but I'm wondering why the
following query shouldn't work. It seems like it should. With MVCC already
present on the back-end, I can't see any reason other than additional
parsing routines that this couldn't work:
INSERT INTO old_login_id_to_new_account_id(
