Re: SQL functions, INSERT/UPDATE/DELETE RETURNING, and triggers

"Jim C. Nasby" <jim(at)nasby(dot)net> 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