From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Marko Tiikkaja <marko(dot)tiikkaja(at)cs(dot)helsinki(dot)fi> |
Cc: | David Fetter <david(at)fetter(dot)org>, Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, Yeb Havinga <yebhavinga(at)gmail(dot)com>, Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com> |
Subject: | Re: wCTE behaviour |
Date: | 2011-02-24 23:36:03 |
Message-ID: | 2314.1298590563@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Marko Tiikkaja <marko(dot)tiikkaja(at)cs(dot)helsinki(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-02-25 00:02:11 | Re: Named restore points |
Previous Message | Gurjeet Singh | 2011-02-24 23:21:39 | Fwd: psql include file using relative path |