> I'm glad reducing the overhead of out-of-line parameters seems like an > important goal. FWIW, if as Vladimir seems to suggest, it's possible to > bring down the overhead of the v3 extended protocol to somewhere near the > simple protocol, that would obviously be a better solution - it would mean > things work faster here and now, rather than waiting for the v4 protocol. I > have no idea if that's possible though, I'll see if I can spend some time on > understand where the slowdown comes from.
That having been said, I don't really see a reason why we couldn't introduce a new protocol message for this without bumping the protocol version. Clients who don't know about the new message type just won't use it; nothing breaks. Clients who do know about the new message need to be careful not to send it to older servers, but since the server reports its version to the client before the first opportunity to send queries, that shouldn't be too hard. We could add a new interface to libpq that uses the new protocol message on new servers and falls back to the existing extended protocol on older servers. In general, it seems to me that we only need to bump the protocol version if there will be server-initiated communication that is incompatible with existing clients. Anything that the client can choose to initiate (or not) based on the server version should be OK.
That sounds right to me. As you say, the server version is sent early in the startup phase, before any queries are sent to the backend, so frontends know which server they're communicating with.
We could call this "protocol 3.1" since it doesn't break backwards compatibility (no incompatible server-initiated message changes, but it does include a feature that won't be supported by servers which only support 3.0. This could be a sort of "semantic versioning" for the protocol - optional new client-initiated features are a minor version bump, others are a major version bump...
This new client-initiated message would be similar to query, except that it would include the parameter and result-related fields from Bind. The responses would be identical to the responses for the Query message.
