Marko Tiikkaja 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, though.
Tom Lane wrote:
Merlin Moncure 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 x
I would think
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 imp
Jeff Davis 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 effects).
>
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 multi
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 tha
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
Jeff Davis 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 execution?
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 pr
Marko Tiikkaja 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 WITH tuples AS (DELETE
Merlin Moncure writes:
> On Thu, Oct 8, 2009 at 6:52 AM, Robert Haas 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 a
On Thu, Oct 08, 2009 at 11:54:08AM -0400, Merlin Moncure wrote:
> On Thu, Oct 8, 2009 at 6:52 AM, Robert Haas 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
On Thu, Oct 8, 2009 at 6:52 AM, Robert Haas 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:
with x as (delete .
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 RET
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 ...)
INS
On Wed, Oct 7, 2009 at 5:08 PM, Marko Tiikkaja
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 handling DML inside CTEs a
Jaime Casanova wrote:
On Wed, Oct 7, 2009 at 4:20 PM, Marko Tiikkaja
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 in optimizations in this phase
On Wed, Oct 7, 2009 at 4:20 PM, Marko Tiikkaja
wrote:
> Jaime Casanova wrote:
>>
>> On Wed, Oct 7, 2009 at 4:08 PM, Marko Tiikkaja
>> wrote:
>>>
>>> 1) WITH t AS
>>> (UPDATE foo SET bar = bar+1 RETURNING *)
>>> SELECT * FROM t LIMIT 1;
>>>
>>> What's problematic here is that only
Jaime Casanova wrote:
On Wed, Oct 7, 2009 at 4:08 PM, Marko Tiikkaja
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 which, at lea
On Wed, Oct 7, 2009 at 4:08 PM, Marko Tiikkaja
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 which, at least how I see
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 t
21 matches
Mail list logo
