David Fetter <da...@fetter.org> writes: > Sorry that was unclear. Let's imagine there's a DELETE ... RETURNING > in one WITH, and an UPDATE in another that depends on that one. Is > that still allowed?
Yeah it is, although I just noticed that there's a bug in the new implementation: with t1 as (insert into x select ... returning *), t2 as (insert into y select * from t1 returning *) select 1; This should result in the same rows inserted into both x and y, but in git HEAD it fails to insert anything into y. The reason is that the ExecutorEnd scan first processes the ModifyTable node for x, and cycles it to completion, discarding the results --- but we needed the CteScan in t2 to see those rows. There's a related case in the regression tests, but it works because the outer query does fetch from both WITH clauses, so there's no need to do anything at ExecutorEnd time. The first solution that comes to mind is to pay attention to the interdependencies of the CTEs, and perform the cleanup in an appropriate order (here, the ModifyTable for y needs to be cycled first). I'm not sure if there's a nicer way. We'll eventually want some interdependency tracking for CTEs anyway, if we're ever to support mutual recursion, so it'd not be completely single-purpose code. regards, tom lane -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers