On 2011-02-25 1:36 AM, Tom Lane wrote:
> Marko Tiikkaja<marko.tiikkaja@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