On Thu, Jul 20, 2006 at 08:46:13PM -0400, Tom Lane wrote: > 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.
I misread that to include SRFs, but it got me thinking... another possibility would be to changes VALUES() so that it was treated as a function, and allow it to have an arbitrary number of parameters. That would automatically allow the case of SELECT * FROM VALUES(...). INSERT would need to learn how to accept SRFs, but that would have the nice side-effect of allowing INSERT INTO table set_returning_function(); Of course, adding the ability for functions to have an arbitrary argument list could well be more complex than any of the options discussed thusfar... though it would be a very handy feature to have. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings