From: | David Fetter <david(at)fetter(dot)org> |
---|---|
To: | "Jim C(dot) Nasby" <jim(at)nasby(dot)net> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: SQL functions, INSERT/UPDATE/DELETE RETURNING, and triggers |
Date: | 2006-10-12 18:44:05 |
Message-ID: | 20061012184404.GC24237@fetter.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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(at)fetter(dot)org> http://fetter.org/
phone: +1 415 235 3778 AIM: dfetter666
Skype: davidfetter
Remember to vote!
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-10-12 18:50:34 | Re: SQL functions, INSERT/UPDATE/DELETE RETURNING, and triggers |
Previous Message | Jonah H. Harris | 2006-10-12 18:37:46 | Re: SQL functions, INSERT/UPDATE/DELETE RETURNING, and triggers |