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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
