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

On Thu, Oct 12, 2006 at 01:28:18PM -0500, Jim C. Nasby wrote:
> 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.  This'd allow the query to be executed completely,
> > and its triggers fired, before we return from the SQL function.
> 
> Would this only affect RETURNING queries that are returning data via
> a SRF? ISTM that pushing to a tuplestore is a lot of extra work for
> simpler cases like INSERT INTO table DELETE FROM queue_table WHERE
> ...  RETURNING *; Even for the case of just going back to the
> client, it seems like a fair amount of overhead.

More generally, would this change impede promoting RETURNING to work
just as VALUES does in 8.2 (i.e. being able to join RETURNING results,
etc.)?

Cheers,
D
-- 
David Fetter <david@fetter.org> http://fetter.org/
phone: +1 415 235 3778        AIM: dfetter666                             Skype: davidfetter

Remember to vote!