From: | "Jim C(dot) Nasby" <jim(at)nasby(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: SQL functions, INSERT/UPDATE/DELETE RETURNING, and triggers |
Date: | 2006-10-12 18:28:18 |
Message-ID: | 20061012182818.GK28647@nasby.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)nasby(dot)net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
From | Date | Subject | |
---|---|---|---|
Next Message | Jonah H. Harris | 2006-10-12 18:37:46 | Re: SQL functions, INSERT/UPDATE/DELETE RETURNING, and triggers |
Previous Message | D'Arcy J.M. Cain | 2006-10-12 18:24:22 | Re: New version of money type |