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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
