Here is a preliminary patch for removing Query from the executor API. I've created a new "top plan" node type, which I chose to call PlannedStmt. I have not yet done anything about replacing the runtime representation of the range table, but I'm intending to tackle that after completing this part.
One thing that made this uglier than I was expecting is that for statements that are prepared via the FE/BE protocol, we may choose not to plan until the Bind message is received. That means that PreparedStatement has to be prepared to store either Query trees or finished Plan trees, and so I couldn't simply remove the storage of Query trees as is possible in other contexts. To try to minimize the amount of duplicated code, I changed some of the support routines in utility.c so that they could work on either Query or PlannedStmt (or bare utility statements, as they already did). It's still a bit ugly though, particularly in prepare.c --- see for instance FetchPreparedStatementResultDesc. Anyone see a nicer way to do it? (This is gonna have some consequences for the plan-invalidation project too; AFAICS we'll have to be prepared to tend to invalidation of a parsed-and-rewritten-but-not-planned query. Or else not do any advance parse/rewrite work, but that sort of takes the point out of a "prepared" statement...) Something else that emerged from this is that the SQL-level PREPARE and EXECUTE commands are unprepared to cope with a protocol-prepared statement that wasn't actually planned. For the moment I just made them throw elog(ERROR), and that may be the only solution that's reasonable to back-patch, but it seems like it'd be nice if it worked. OTOH it may be that nobody cares, and then a quick elog is sufficient. Comments? regards, tom lane
---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq