Re: Re: Add minor version to v3 protocol to allow changes without breaking backwards compatibility

On Mon, Jan 23, 2012 at 10:34:12AM -0500, Robert Haas wrote:
> On Mon, Jan 23, 2012 at 9:36 AM, Florian Weimer <fweimer(at)bfk(dot)de> wrote:
> > * Robert Haas:
> >>> In this particular case, I knew that the change was coming and could
> >>> push updated Java and Perl client libraries well before the server-side
> >>> change hit our internal repository, but I really don't want to have to
> >>> pay attention to such details.
> >>
> >> But if we *don't* turn this on by default, then chances are very good
> >> that it will get much less use. ?That doesn't seem good either. ?If
> >> it's important enough to do it at all, then IMHO it's important enough
> >> for it to be turned on by default. ?We have never made any guarantee
> >> that the binary format won't change from release to release.
> >
> > The problem here are libpq-style drivers which expose the binary format
> > to the application. ?The Java driver doesn't do that, but the Perl
> > driver does. ?(However, both transparently decode BYTEA values received
> > in text format, which led to the compatibility issue.)
>
> I can see where that could cause some headaches... but it seems to me
> that if we take that concern seriously, it brings us right back to
> square one. If breaking the binary format causes too much pain to
> actually go do it, then we shouldn't change it until we're breaking
> everything else anyway (i.e. new protocol version, as Tom suggested).

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.