On Mon, Jan 23, 2012 at 11:15 AM, Noah Misch <noah@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
areenough
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