| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
| Cc: | Gregory Stark <stark(at)enterprisedb(dot)com>, David Fetter <david(at)fetter(dot)org>, Jan Szumiec <jan(dot)szumie(at)infiniteloop(dot)eu>, pgsql-bugs(at)postgresql(dot)org |
| Subject: | Re: BUG #3320: Error when using INSERT...RETURNING as a subquery |
| Date: | 2007-05-30 02:41:34 |
| Message-ID: | 23856.1180492894@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Jeff Davis <pgsql(at)j-davis(dot)com> writes:
> On Tue, 2007-05-29 at 18:10 +0100, Gregory Stark wrote:
>> It has the same problem that SELECT triggers have. How many rows should you
>> expect that subquery to insert, update, or delete if it's used in a join
>> clause? Or in the where clause of another insert/update/delete statement?
> We could handle it essentially like a volatile set-returning function.
Uh-huh. Please provide a concise, accurate definition of what that
does. For extra points, be sure it describes the behavior of all recent
Postgres versions. (And after that, we could argue about whether we
actually *like* the described behavior ... which I'll bet we won't.)
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Sullivan | 2007-05-30 11:26:47 | Re: BUG #3321: No start service |
| Previous Message | Jeff Davis | 2007-05-29 23:42:17 | Re: BUG #3320: Error when using INSERT...RETURNING as a subquery |