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 <[EMAIL PROTECTED]> http://fetter.org/ phone: +1 415 235 3778 AIM: dfetter666 Skype: davidfetter Remember to vote! ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
