| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Marko Tiikkaja <marko(at)joh(dot)to> |
| Cc: | Boszormenyi Zoltan <zb(at)cybertec(dot)at>, Karol Trzcionka <karlikt(at)gmail(dot)com>, David Fetter <david(at)fetter(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: GSOC13 proposal - extend RETURNING syntax |
| Date: | 2013-10-04 14:22:36 |
| Message-ID: | CA+TgmoZ5-s_tCOE-jPgJH0tREARVr3AeGYS07E84ZAnzygVUwQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Oct 4, 2013 at 5:04 AM, Marko Tiikkaja <marko(at)joh(dot)to> wrote:
> I might be completely in the woods here, but I believe something like this
> was attempted by Karol earlier, and it failed if two concurrent transactions
> did something similar to:
>
> UPDATE foo SET a = a + 1 RETURNING BEFORE.a;
>
> Both of them would see BEFORE.a = 0, because that's what the "a" evaluated
> to from the tuple we got before EvalPlanQual.
>
> But maybe what you're suggesting doesn't have this problem?
Hmm, it probably does. That explains why there are executor changes
here; I guess they need some comments to explain their purpose.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Rowley | 2013-10-04 14:23:52 | pg_dump insert with column names speedup |
| Previous Message | Fujii Masao | 2013-10-04 14:22:22 | Re: pg_stat_statements: calls under-estimation propagation |