TopPlan, again

While thinking about having a centralized plan cache for managing plan
invalidation, I got annoyed again about the fact that the executor needs
access to the Query tree. This means that we'll be storing *three*
representations of any cached query: raw parsetree for possible
regeneration, plus parsed Query tree and Plan tree.

We've repeatedly discussed getting rid of execution-time access to the
Query structure --- here's one old message about it:
http://archives.postgresql.org/pgsql-hackers/1999-02/msg00388.php
and here's a recent one:
http://archives.postgresql.org/pgsql-hackers/2006-08/msg00734.php
I think it's time to bite the bullet and do that.

After looking over the code it seems that the executor needs a limited
subset of the Query fields, namely

commandType
canSetTag
rtable
returningList
returningLists
into
intoOptions
intoOnCommit (why is this separate from intoOptions?)
intoTableSpaceName
rowMarks
resultRelation
resultRelations
nParamExec (currently in topmost Plan node)

which I think we should put into a new TopPlan node type.
returningLists and resultRelations could be removed from Query;
also, we might need only the list forms and not the singleton
returningList/resultRelation fields in TopPlan.

The other big problem is the rangetable (rtable): currently it contains
Query trees for subqueries (including views) so unless we clean that up
we aren't going to be all that far ahead in terms of reducing the
overhead. I'm envisioning creating a "compact" rangetable entry struct
with just the fields the executor needs:

rtekind
relid
eref (might only need the table alias name not the column names)
requiredPerms
checkAsUser

and flattening subquery rangetables into the main list, so that there's
just one list and rangetable indexes are unique throughout a plan tree.
That will allow subqueries to execute with the same EState as the main
query and thus simplify nodeSubplan and nodeSubqueryScan. This list
will also provide a simple way for the plan cache module to know which
relations to lock before determining whether the plan has been invalidated.

Comments, objections? Also, any thoughts about the names to use for
these new node types? As I commented last year, I'm not completely
happy with "TopPlan" because it won't actually be a subtype of Plan,
but I don't have a better idea. Also I'm unsure what to call the
cut-down RangeTblEntry struct; maybe RunTimeRangeTblEntry?

regards, tom lane