On Thu, Oct 3, 2013 at 7:54 PM, Karol Trzcionka <karlikt@gmail.com> wrote:
> Compare EXPLAIN ANALYZE VERBOSE on your statement and on "patched"
> workflow. I can see significant difference. And your "after" returns the
> value after whole the work (after trigger fired) as I know (I don't know
> if it is needed or not, I only point at the difference).
Sure, I'm not saying we should implement it that way. I'm just
pointing out that the ability already exists, at the executor level,
to return either tuple. So I think the executor itself shouldn't need
to be changed; it's just a matter of getting the correct plan tree to
pop out.
> While planning/analyzing the problem there were many ideas about hot to
> solve it.
Do you have a link to previous discussion on the mailing list?
> I think we can do it by modify the Var structure (add some kind of flag
> while generating the vars in parser?) but I'm not sure if it is good
> idea. The major issue is to know if the Var/TargetEntry references to
> the real alias "BEFORE" (named with "AS" syntax or even the real
> table-name - I can see there is no difference in code) or the virtual
> (from feature patch) "BEFORE". Doing it in parser (more "low-level")
> would be very awful - we'd need to check in which part of statement
> BEFORE/AFTER is placed (it is not allowed to use it in the other places
> than in "RETURNING"). We don't want to make "BEFORE" and "AFTER"
> restricted keywords.
You're right, it can't happen actually in the parser. But maybe it
can happen during parse analysis. I'd spend some time looking at
transformColumnRef(), because that's where we translate things x.y
into Var nodes. I'm not positive there's enough information available
at that stage, but if p_target_rangetblentry is populated at that
point, you should be able to make AFTER.x translate to a Var
referencing that range table entry. It's a bit less clear how we know
that we're inside the returning-list at that point; I'm not sure how
much work it would be to pass that information down. But I think it's
worth looking at.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company