Tom Lane wrote:
Merlin Moncure mmonc...@gmail.com writes:
Is the above form:
with x as (delete .. returning *) insert into y select * from x
going to be allowed? I was informed on irc that it wasn't...it would
have to be written as:
insert into y with x as (delete .. returning *) select * from
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi writes:
I'm looking at this, and if I understood correctly, you're suggesting
we'd add a WithClause to InsertStmt. Would we also allow this?
Yeah, we could eventually do all that. I think supporting it in SELECT
would be plenty to start with,
Jeff Davis pg...@j-davis.com writes:
On Fri, 2009-10-09 at 02:23 +0300, Peter Eisentraut wrote:
I think I'd want writable subqueries instead of only writable CTEs.
I think the original motivation was that it's more clear that a CTE is
separated and can only be executed once (if it has side
Added to TODO:
Allow INSERT/UPDATE/DELETE ... RETURNING in common table expressions
* http://archives.postgresql.org/pgsql-hackers/2009-10/msg00472.php
---
Marko Tiikkaja wrote:
I've made progress in
On Wed, Oct 7, 2009 at 5:08 PM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi wrote:
I've made progress in implementing writeable CTEs (repo at
git://git.postgresql.org/git/writeable_cte.git , branch actually_write)
and I've hit a few corner-cases which have lead me to think that we
should be
Robert Haas wrote:
This has one MAJOR disadvantage: all the tuples from the CTE queries
have to be buffered someplace, rather than streamed from the subquery
up to the main query. For what may turn out to be pretty common uses
cases like WITH tuples AS (DELETE FROM big_table_1 RETURNING ...)
I wrote:
3)WITH t1 AS
(UPDATE foo SET bar=bar+1 RETURNING *),
t2 AS
(UPDATE baz SET bat=bat+1 RETURNING *)
VALUES (true);
This isn't probably the most common situation either, but I think it's
worth looking at; the user wants to update two different tables, but
ignore the
On Thu, Oct 8, 2009 at 6:52 AM, Robert Haas robertmh...@gmail.com wrote:
up to the main query. For what may turn out to be pretty common uses
cases like WITH tuples AS (DELETE FROM big_table_1 RETURNING ...)
INSERT INTO big_table_2 ... this is going to suck pretty bad. I
Is the above form:
On Thu, Oct 08, 2009 at 11:54:08AM -0400, Merlin Moncure wrote:
On Thu, Oct 8, 2009 at 6:52 AM, Robert Haas robertmh...@gmail.com wrote:
up to the main query. For what may turn out to be pretty common uses
cases like WITH tuples AS (DELETE FROM big_table_1 RETURNING ...)
INSERT INTO
Merlin Moncure mmonc...@gmail.com writes:
On Thu, Oct 8, 2009 at 6:52 AM, Robert Haas robertmh...@gmail.com wrote:
up to the main query. For what may turn out to be pretty common uses
cases like WITH tuples AS (DELETE FROM big_table_1 RETURNING ...)
INSERT INTO big_table_2 ... this is going
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi writes:
Robert Haas wrote:
This has one MAJOR disadvantage: all the tuples from the CTE queries
have to be buffered someplace, rather than streamed from the subquery
up to the main query. For what may turn out to be pretty common uses
cases like
On Thu, 2009-10-08 at 12:57 -0400, Tom Lane wrote:
I also agree with bumping the CID in between.
Do you mean bump the CID in between each DML statement, or between the
last DML statement and the main query? If the former, how should we
choose the order of execution?
I'm not sure if this is a
Jeff Davis pg...@j-davis.com writes:
On Thu, 2009-10-08 at 12:57 -0400, Tom Lane wrote:
I also agree with bumping the CID in between.
Do you mean bump the CID in between each DML statement, or between the
last DML statement and the main query? If the former, how should we
choose the order of
On Thu, 2009-10-08 at 15:11 -0400, Tom Lane wrote:
I'm not sure if this is a problem, but it seems like we're essentially
allowing a complex transaction to take place in one statement. Is that
what we want?
Yeah, I think that's more or less the point ...
I'm still trying to ponder the
On Thu, 2009-10-08 at 12:34 -0700, Jeff Davis wrote:
I'm still trying to ponder the consequences of this. Most people
assume
that a single statement means that everything in the statement happens
at once (intuitively). The few cases where that's not true are special
commands or things that we
On Fri, 2009-10-09 at 02:23 +0300, Peter Eisentraut wrote:
INSERT INTO tab1 SELECT ... FROM tab1
clearly requires the SELECT to be distinctly before the INSERT.
That's effectively only one thing: assigning a relation (the result of
the select) to a variable (tab1). I was talking about
I've made progress in implementing writeable CTEs (repo at
git://git.postgresql.org/git/writeable_cte.git , branch actually_write)
and I've hit a few corner-cases which have lead me to think that we
should be handling DML inside CTEs a bit differently. Before I go on
implementing this, I'd like
On Wed, Oct 7, 2009 at 4:08 PM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi wrote:
1) WITH t AS
(UPDATE foo SET bar = bar+1 RETURNING *)
SELECT * FROM t LIMIT 1;
What's problematic here is that only 1 row is read from the CTE, meaning
also that only one row is updated
Jaime Casanova wrote:
On Wed, Oct 7, 2009 at 4:08 PM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi wrote:
1) WITH t AS
(UPDATE foo SET bar = bar+1 RETURNING *)
SELECT * FROM t LIMIT 1;
What's problematic here is that only 1 row is read from the CTE, meaning
also that only
On Wed, Oct 7, 2009 at 4:20 PM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi wrote:
Jaime Casanova wrote:
On Wed, Oct 7, 2009 at 4:08 PM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi wrote:
1) WITH t AS
(UPDATE foo SET bar = bar+1 RETURNING *)
SELECT * FROM t LIMIT 1;
Jaime Casanova wrote:
On Wed, Oct 7, 2009 at 4:20 PM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi wrote:
Right. This is exactly what I'm trying to do, except I think we could
easily optimize this case and store only the first processed row inside
the CTE.
why? we don't should be thinking
21 matches
Mail list logo
