On 2011-02-25 1:36 AM, Tom Lane wrote:
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.)
Without hacking it broke when PQdescribePrepared was called on a
prepared query like:
WITH t AS (DELETE FROM foo)
SELECT 1;
Not sure if that's an actual problem, but it seemed like something worht
fixing.
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?
Honestly, I have no idea. It might be a leftover from the previous
design. If it looks like it's easy to support, then go for it.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
