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