Martijn van Oosterhout <[EMAIL PROTECTED]> writes:
> On Tue, Dec 18, 2007 at 02:48:23PM +0100, [EMAIL PROTECTED] wrote:
>> But then, I still don't get the relationship between
>>
>> INNER, OUTER varnos on the one side and
>> ecxt_scantuple, ecxt_outertuple and ecxt_innertuple on the other side.
>>
>> May a non-leaf node refer to a Var with a 'normal' scan varno or only to
>> INNER and OUTER varnos?
> They're just variables. When you call a subnode it returns a
> tupletableslot. When you want to return a tuple to your parent, you
> just return it.
More to the point, this is all dependent on how the planner's setrefs.c
sets up the varnos in the finished plan tree; those varnos will
determine which slot ExecEvalVar looks in at runtime. Historically
there was some inconsistency in how single-input non-leaf plan nodes
did things --- looking at 8.2, Agg and Group nodes got their Vars set up
as varno 0 (compelling the use of scantuple to hold the subplan output
tuple at runtime), Result got set up with varno OUTER (compelling use of
outertuple), and it looks like none of the other plan node types in this
category do expression evaluation at all. As of 8.3 I made all three use
varno OUTER in order to simplify setrefs.c a tad. It would have been
about equally consistent to use varno 0 across the board; I think I did
it this way because it made fewer cases for the deparsing code in
ruleutils.c to deal with.
None of this seems to have much to do with Peter's real problem though;
he's looking for a way to get at values that are being computed in the
current plan node, not by its input. I think he needs to invent a
back-channel for his special functions and node type to communicate
through. Perhaps something similar to the way aggregate functions can
communicate with nodeAgg.c via AggState in fcinfo->context would work.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
