On Mon, Jan 23, 2012 at 11:06 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Mon, Jan 23, 2012 at 11:15 AM, Noah Misch <n...@leadboat.com> wrote: >> As I said upthread, and you appeared to agree, the protocol is independent of >> individual data type send/recv formats. Even if we were already adding >> protocol v4 to PostgreSQL 9.2, having array_send() change its behavior in >> response to the active protocol version would be wrong. > > Sure, it's not directly related to the active protocol version, but my > point is that we need to decide whether we need an autonegotiation > mechanism or some kind, or not. We can reasonably decide that: > > 1. It's OK to change the binary format incompatibly, and clients must > be prepared to deal with that, possibly assisted by a > backward-compatibility GUC. > > -or else- > > 2. It's not OK to change the binary format incompatibility, and > therefore we need some kind of negotiation mechanism to make sure that > we give the new and improved format only to clients that can cope with > it. > > Not being responsible from the maintenance of any PostgreSQL drivers > whatsoever, I don't have a strong feeling about which of these is the > case, and I'd like us to hear from the people who do. What I do think > is that we can't look at a GUC (however named) as a poor man's > replacement for #2. It's not gonna work, or at least not very well. > If the default is off, then clients have to go through a round-trip to > turn it on, which means that every client will have to decide whether > to pay the price of turning it on (and possibly not recoup the > investment) or whether to leave it off (and possibly get hosed if many > large arrays that would have met the criteria for the optimization are > transferred). Furthermore, if we turn it on by default, drivers and > applications that haven't been updated will deliver corrupted results. > None of that sounds very good to me. If there are enough > dependencies on the details of the binary format that we can't afford > to just change it, then we'd better have a cheap and reliable way for > clients to negotiate upward - and a GUC is not going to give us that.
Trying to solve it with startup-time negotiation, or some GUC is a dead end, in the sense that it will actively discourage any kind of pass-through protocol processing. If simple protocol processor (~pgbouncer) needs to know about some GUC, and tune it on-the-fly, it's not a payload feature, it's a protocol feature. Instead this should be solved with extending the per-query text/bin flag to include version info and maybe also type groups. Some way of saying "numerics:9.0-bin", "the-rest:8.4-text". The groups would also solve the problem with no way of turning on binary formats on result columns safely. The flags could be text (~http accept), or maybe integers for more efficiency (group code: group format ver). -- marko -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers