From: | Marko Tiikkaja <marko(at)joh(dot)to> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
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 09:04:04 |
Message-ID: | 524E8484.10207@joh.to |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 10/4/13 12:28 AM, Robert Haas wrote:
> In fact, we can already get approximately the
> desired effect already:
>
> rhaas=# update foo as after set a = before.a + 1 from foo as before
> where before.a = after.a returning before.a, after.a;
> a | a
> ---+---
> 1 | 2
> (1 row)
>
> Now this is a hack, because we don't really want to add an extra
> scan/join just to get the behavior we want. But it seems to me
> significant that this processing makes Vars that refer to the target
> table refer to the new values, and if we got rid of it, they'd refer
> to the old values. Can't we contrive to make AFTER.x parse into the
> same Var node that x currently does? Then we don't need an RTE for
> it.
This part sounds reasonable from here.
> And maybe BEFORE.x ought to parse to the same node that just
> plain x does but with some marking, or some other node wrapped around
> it (like a TargetEntry with some flag set?) that suppresses this
> processing. I'm just shooting from the hip here; that might be wrong
> in detail, or even in broad strokes, but it just looks to me like the
> additional RTE kind is going to bleed into a lot of places.
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?
Regards,
Marko Tiikkaja
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2013-10-04 10:06:34 | Re: [RFC] Extend namespace of valid guc names |
Previous Message | Karol Trzcionka | 2013-10-04 08:42:32 | Re: GSOC13 proposal - extend RETURNING syntax |