Re: 7.3 schedule

Neil Conway <nconway@klamath.dyndns.org> writes:
> On the other hand, there are already a few reasons to make some
> changes to the FE/BE protocol (NOTIFY messages, transaction state,
> and now possibly PREPARE/EXECUTE -- anything else?).

Passing EXECUTE parameters without having them go through the parser
could possibly be done without a protocol change: use the 'fast path'
function-call code to pass binary parameters to a function that is
otherwise equivalent to EXECUTE.

On the other hand, the 'fast path' protocol itself is pretty horribly
misdesigned, and I'm not sure I want to encourage more use of it until
we can get it cleaned up (see the comments in backend/tcop/fastpath.c).
Aside from lack of robustness, I'm not sure it can work at all for
functions that don't have prespecified types and numbers of parameters.

The FE/BE COPY protocol is also horrible.  So yeah, there are a bunch of
things we *could* fix if we were ready to take on a protocol change.

My own thought is this might be better held for 7.4, though.  We are
already going to be causing application programmers a lot of pain with
the schema changes and ensuing system-catalog revisions.  That might
be enough on their plates for this cycle.

In any case, for the moment I think it's fine to be working on
PREPARE/EXECUTE support at the SQL level.  We can worry about adding
a parser bypass for EXECUTE parameters later.

			regards, tom lane