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
On 23 April 2012 21:49, Nick Apperson apper...@gmail.com 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
On Tue, Apr 24, 2012 at 6:49 AM, Nick Apperson apper...@gmail.com 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
On Tue, Apr 24, 2012 at 08:12:10AM +1000, Chris Angelico wrote:
On Tue, Apr 24, 2012 at 6:49 AM, Nick Apperson apper...@gmail.com 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
On Tue, Apr 24, 2012 at 11:30 AM, David Fetter da...@fetter.org 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
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
