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

Reply via email to