On Thu, 2002-04-11 at 18:14, Tom Lane wrote:
> 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.
Also _universal_ binary on-wire representation for types would be a good
thing. There already are slots in pg_type for functions to do that. By
doing so we could also avoid parsing text representations of field data.
> 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.
IIRC someone started work on modularising the network-related parts with
a goal of supporting DRDA (DB2 protocol) and others in future.
-----------------
Hannu
