Re: Slowness of extended protocol

Just a note from me - I also agree this thread evolved (or rather devolved)
in a rather unproductive and strange way.

One important note that came out, though, is that adding a new client
message does have a backwards compatibility issue - intelligent proxies
such as pgbouncer/pgpool will probably break once they see an unknown
client message. Even if they don't, they may miss potentially important
information being transmitted to the server. Whether this is a deal-breaker
for introducing new messages is another matter (I personally don't think
so).

On Tue, Aug 23, 2016 at 4:54 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:

> On 2016-08-23 11:42:53 -0400, Robert Haas wrote:
> > I think this could possibly be done, but it seems a lot better to me
> > to just bite the bullet and add a new protocol message. That was
> > proposed by Tom Lane on July 31st and I think it's still by far the
> > best and easiest idea proposed, except I think we could introduce it
> > without waiting for a bigger rework of the protocol if we design the
> > libpq APIs carefully. Most of the rest of this thread seems to have
> > devolved into an argument about whether this is really necessary,
> > which IMHO is a pretty silly argument, instead of focusing on how it
> > might be done, which I think would be a much more productive
> > conversation.
>
> I agree about the odd course of the further discussion, especially the
> tone was rather odd. But I do think it's valuable to think about a path
> that fixes the issue without requiring version-dependant adaptions in
> all client drivers.
>
> Greetings,
>
> Andres Freund
>