Delaying the planning of unnamed statements until Bind

Hello pgsql-hackers,

Following a recent discussion on the JDBC list
(http://archives.postgresql.org/pgsql-jdbc/2004-05/msg00100.php) I'm
looking at modifying when unnamed statements received via a v3 protocol
Parse message are planned. The idea is to delay planning until the Bind
message arrives, so that the planner benefits from knowing the actual
parameter values in use. This means that clients such as JDBC can use an
unnamed Parse/Bind as a way to provide typed and/or binary parameter
values without running the risk of worsening the query plan.

As this is my first excursion into the backend code (and the first time
I've touched any C for about a year, for that matter) I'd like to get a
sanity check on what I'm doing..

So far my changes involve:

1. Add a ParamListInfo parameter to pg_plan_query(), pg_plan_queries(),
planner(); this provides actual parameter values or NULL if
unavailiable. All existing callers except execute_bind_message pass NULL.

2. In execute_parse_message, if parsing into the unnamed statement,
first parse the query. If there are any parameters present, don't plan
the query yet (set unnamed_stat_pstmt->plan_list = NULL). Otherwise,
parse and plan as normal.

3. In execute_bind_message, if the source statement is not planned
(plan_list == NULL), plan it, passing the concrete parameter values
received in the Bind message. The planning happens using the target
portal's memory context; the resulting plan_list is only used for this
portal and the source statement remains unplanned. Move the call to
PortalDefineQuery() so that it occurs after parameters have been
received and any planning has been done.

4. In planner(), if parameters are provided, replace Param nodes with
Const nodes in the query tree where appropriate.

For 4) I have a couple of options:

a) thread a ParamListInfo parameter through the planner code. Pass it
to eval_const_expressions(). Make eval_const_expressions() do the
Param->Const replacement where possible in the mutated tree it produces.

b) if parameters are provided, do the Param->Const replacement at the
start of planner() using a custom tree walker.

4a) appears more efficient as it doesn't need another intermediate tree
copy, but it requires threading the parameter values through many
planner functions. There are quite a few (20-30ish?) functions affected.

4b) appears simpler to implement but requires more tree copying at runtime.

...

Does this look like a reasonable approach to take? Any suggestions, or
gotchas I've missed?

-O