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...
Adding a new message is not backward compatible since it will fail in pgbouncer kind of deployments.
Suppose there's "new backend", "old pgbouncer", "new client" deployment.
If the client tries to send the new message, it will fail since pgbouncer would have no idea what to do with that new message.
That's definitely a valid point. But do you think it's a strong enough argument to avoid ever adding new messages?
On the other hand, usage of some well-defined statement name to trigger the special case would be fine: all pgbouncer versions would pass those parse/bind/exec message as if it were regular messages.
Can you elaborate on what that means exactly? Are you proposing to somehow piggyback on an existing message (e.g. Parse) but use some special statement name that would make PostgreSQL interpret it as a different message type? Apart from being a pretty horrible hack, it would still break pgbouncer, which has to actually inspect and understand SQL being sent to the database (e.g. to know when transactions start and stop).
