Re: SQL functions, INSERT/UPDATE/DELETE RETURNING, and triggers
От | Jim C. Nasby |
---|---|
Тема | Re: SQL functions, INSERT/UPDATE/DELETE RETURNING, and triggers |
Дата | |
Msg-id | 20061012182818.GK28647@nasby.net обсуждение исходный текст |
Ответ на | SQL functions, INSERT/UPDATE/DELETE RETURNING, and triggers (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: SQL functions, INSERT/UPDATE/DELETE RETURNING, and triggers
Re: SQL functions, INSERT/UPDATE/DELETE RETURNING, and triggers |
Список | 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 по дате отправления: