Vladimir Sitnikov <sitnikov.vladimir@gmail.com> writes:
> The point is "adding a message to current v3 protocol is not a backward
> compatible change".
> The problem with adding new message types is not only "client support", but
> deployment issues as well: new message would require simultaneous upgrade
> of both backend, client, and pgbouncer.
Right ...
> It could make sense to add some kind of transparent extensibility to the
> protocol, so clients can just ignore unknown message types.
I'm not really sure what use that particular behavior would be. We
certainly want to try to have some incremental extensibility in there
when we do v4, but I think it would more likely take the form of a way
for client and server to agree on which extensions they support.
> 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.
I do not accept this idea that retroactively defining special semantics
for certain statement names is not a protocol break. If it causes any
change in what the server's response would be, then it is a protocol
break.
> Note: it is quite easy to invent a name that is not yet used in the wild,
> so it is safe.
Sir, that is utter nonsense. And even if it were true, why is it that
this way would safely pass through existing releases of pgbouncer when
other ways would not? Either pgbouncer needs to understand what it's
passing through, or it doesn't.
regards, tom lane
