Re: SQL functions, INSERT/UPDATE/DELETE RETURNING, and triggers - Mailing list pgsql-hackers

From Jim C. Nasby
Subject Re: SQL functions, INSERT/UPDATE/DELETE RETURNING, and triggers
Date
Msg-id 20061012182818.GK28647@nasby.net
Whole thread Raw
In response to SQL functions, INSERT/UPDATE/DELETE RETURNING, and triggers  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: SQL functions, INSERT/UPDATE/DELETE RETURNING, and triggers  (David Fetter <david@fetter.org>)
Re: SQL functions, INSERT/UPDATE/DELETE RETURNING, and triggers  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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.
-- 
Jim Nasby                                            jim@nasby.net
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)


pgsql-hackers by date:

Previous
From: "D'Arcy J.M. Cain"
Date:
Subject: Re: New version of money type
Next
From: "Jonah H. Harris"
Date:
Subject: Re: SQL functions, INSERT/UPDATE/DELETE RETURNING, and triggers