Date: Fri, 21 Jul 2006 09:08:32 -0500
From: "Jim C. Nasby" <jnasby@pervasive.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Joe Conway <mail@joeconway.com>,
	Christopher Kings-Lynne <chris.kings-lynne@calorieking.com>,
	"Hackers (PostgreSQL)" <pgsql-hackers@postgresql.org>,
	Andrew Dunstan <andrew@dunslane.net>, Bernd Helmle <mailings@oopsware.de>,
	Peter Eisentraut <peter_e@gmx.net>,
	Susanne Ebrecht <susanne.ebrecht@credativ.de>
Subject: Re: [PATCHES] 8.2 features?
Message-ID: <20060721140832.GD83250@pervasive.com>
References: <15212.1153279954@sss.pgh.pa.us> <44BDB2F5.7080003@joeconway.com>
	<44BEA710.6060700@joeconway.com> <23198.1153367887@sss.pgh.pa.us>
	<44BF0382.2010501@joeconway.com> <23454.1153370214@sss.pgh.pa.us>
	<44BF122F.1080200@joeconway.com> <23927.1153373971@sss.pgh.pa.us>
	<44C00E1E.1000405@joeconway.com> <14047.1153442773@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <14047.1153442773@sss.pgh.pa.us>
User-Agent: Mutt/1.5.11

On Thu, Jul 20, 2006 at 08:46:13PM -0400, Tom Lane wrote:
> Joe Conway <mail@joeconway.com> 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      jnasby@pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461