Joe Conway <[EMAIL PROTECTED]> writes: > I'm liking this too. But when you say "jointree node", are you saying to > model the new node type after NestLoop/MergeJoin/HashJoin nodes? These > are referred to as "join nodes" in ExecInitNode. Or as you mentioned a > couple of times, should this look more like an Append node?
No, I guess I confused you by talking about the executor representation at the same time. This is really unrelated to the executor. The join tree I'm thinking of here is the data structure that dangles off Query.jointree --- it's a representation of the query's FROM clause, and (at present) can contain RangeTblRef, FromExpr, and JoinExpr nodes. See the last hundred or so lines of primnodes.h for some details. The jointree is used by the planner to compute the plan node tree that the executor will run, but it's not the same thing. There are basically two ways you could go about this: 1. Make a new jointree leaf node type to represent a VALUES construct, and dangle the list of lists of expressions off that. 2. Make a new RangeTblEntry type to represent a VALUES construct, and just put a RangeTblRef to it into the jointree. The expressions dangle off the RangeTblEntry. Offhand I'm not certain which of these would be cleanest. The second way has some similarities to the way we handle set operation trees (UNION et al), so it might be worth looking at that stuff. However, being a RangeTblEntry has a lot of baggage (eg, various routines expect to find an RTE alias, column names, column types, etc) and maybe we don't need all that for VALUES. One advantage of the first way is that you could use the same node type for the "raw parser output" delivered by gram.y. This is a bit of a type cheat, because raw parser output is logically distinct from what parse analysis produces, but we do it in lots of other places too (JoinExpr for instance is used that way). You should in any case have a clear idea of the difference between the raw and analyzed parser representations --- for instance, the raw form won't contain any datatype info, whereas the analyzed form must. This might or might not need to be visible directly in the VALUES node --- it might be that you can rely on the datatype info embedded in the analyzed expressions. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend