"Jim C. Nasby" <[EMAIL PROTECTED]> writes: > On Thu, Oct 12, 2006 at 12:19:24PM -0400, Tom Lane wrote: >> I think the most promising answer may be to push RETURNING rows into a >> TupleStore and then read them out from there, which is pretty much the >> same approach we adopted for RETURNING queries inside portals.
> Would this only affect RETURNING queries that are returning data via a > SRF? Right, and specifically an SQL-language function. > ISTM that pushing to a tuplestore is a lot of extra work for I'm not entirely convinced of that --- the overhead of getting down through functions.c and ExecutorRun into the per-tuple loop isn't trivial either. It wouldn't work at all without significant restructuring, in fact, because as execMain stands we'd be firing "per statement" triggers once per row if we tried to handle RETURNING queries the same way that SQL functions currently handle SELECTs. When you look at the big picture there's a whole lot of call overhead that would go away if SQL functions returned a tuplestore instead of a row at a time. I was toying with the idea that we should make SELECTs return via a tuplestore too, which would allow eliminating the special case of having ExecutorRun return an individual tuple at all. That's not a bugfix though so I'll wait for 8.3 before thinking more about it ... regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org