Marko Tiikkaja <marko.tiikk...@cs.helsinki.fi> writes: > I fixed an issue with the portal logic, and now we use > PORTAL_ONE_RETURNING for wCTE queries, even if the main query is not a > DML or does not have RETURNING. This also means that we materialize the > results of the main query sometimes unnecessarily, but that doesn't look > like an easy thing to fix. PORTAL_ONE_RETURNING as a name is also a bit > misleading now, so maybe that needs changing..
Why is it necessary to hack the portal logic at all? The patch seems to work for me without that. (I've fixed quite a few bugs though, so maybe what this is really doing is masking a problem elsewhere.) Also, why are we forbidding wCTEs in cursors? Given the current definitions, that case seems to work fine too: the wCTEs will be executed as soon as you fetch something from the cursor. Are you just worried about not allowing a case that might be hard to support later? 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