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
