Vladimir Sitnikov <sitnikov.vladi...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers