Re: Writeable CTEs and side effects

Поиск
Список
Период
Сортировка
От Jeff Davis
Тема Re: Writeable CTEs and side effects
Дата
Msg-id 1255046818.16369.174.camel@monkey-cat.sm.truviso.com
обсуждение исходный текст
Ответ на Re: Writeable CTEs and side effects  (Peter Eisentraut <peter_e@gmx.net>)
Ответы Re: Writeable CTEs and side effects  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Joshua D. Drake"
Дата:
Сообщение: Re: Concurrency testing
Следующее
От: u235sentinel
Дата:
Сообщение: Re: postgres 8.3.8 and Solaris 10_x86 64 bit problems?