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 (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
