On Thu, 2002-04-11 at 18:14, Tom Lane wrote: > Neil Conway <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
