peter.trautmeier@gmx.de writes: > I wonder why my ecxt_scantuple has a TupleDesc matching the subplan's > tlist, not my plan's tlist. That's the way it's supposed to be --- the scantuple slot is for scanning your subplan's output. > I have written a new executor node Foo, with corresponding ExecFoo and make_foo functions. I have also written a new Expr type called Bar, along with a ExecEvalBar. > In make_foo I append some Bar columns. When I try to evaluate the Bar columns in ExecFoo via ExecProject, I need the Bar columns to access each other. That makes no sense at all. ExecProject can't be expected to access output columns of the current node --- they haven't been computed yet. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match

Martijn van Oosterhout <kleptog@svana.org> writes: > On Tue, Dec 18, 2007 at 02:48:23PM +0100, peter.trautmeier@gmx.de 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