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
