"Jonah H. Harris" <jonah.harris@gmail.com> writes:
> On 8/11/06, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 4. Treat PORTAL_ONE_RETURNING like PORTAL_UTIL_SELECT rather than
>> like PORTAL_ONE_SELECT; that is, execute the query to completion
>> on first call and stash the results in a tuplestore until the
>> client fetches them.
> I agree that it's inefficient, but am trying to think of any other
> positive reasons for doing #4 instead.
I found a showstopper reason why it has to be done this way: the AFTER
TRIGGER code isn't capable of dealing with interleaved execution of
different queries (it can basically only track nested queries).
Possibly that could be improved in the future, but for 8.2 I think
we're stuck with using a tuplestore.
One optimization I think might not be too hard is to bypass the
tuplestore and stream RETURNING tuples directly to the client if the
first Execute for the portal doesn't give a row limit (which is surely
the typical case). I don't plan to do that in the first cut though.
regards, tom lane
