Re: Writeable CTEs and side effects

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Marko Tiikkaja <marko(dot)tiikkaja(at)cs(dot)helsinki(dot)fi>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Writeable CTEs and side effects
Date: 2009-10-09 00:06:58
Message-ID: 1255046818.16369.174.camel@monkey-cat.sm.truviso.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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 multiple
assignment.

What if you want to append foo to bar and bar to foo?

WITH
t1 AS (INSERT INTO foo SELECT * FROM bar),
t2 AS (INSERT INTO bar SELECT * FROM foo)
VALUES(1);

That could be an interesting command if we didn't increment the command
counter.

> SELECT * FROM test1 WHERE a IN (UPDATE test2 SET b = b + 1 RETURNING b);
>
> 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).
Depending on how the query is written, it might be less obvious how many
times the subquery should be executed, and it might change based on the
plan.

We could make the same rules for a subquery that has side effects, and
always materialize it. But for now maybe CTEs are a better place to get
the feature working.

Regards,
Jeff Davis

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message u235sentinel 2009-10-09 02:23:24 Re: postgres 8.3.8 and Solaris 10_x86 64 bit problems?
Previous Message Simon Riggs 2009-10-08 23:53:14 Re: Hot Standby 0.2.1