Skip site navigation (1) Skip section navigation (2)

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

From: Noah Misch <noah(at)leadboat(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Mikko Tiihonen <mikko(dot)tiihonen(at)nitorcreations(dot)com>,Merlin Moncure <mmoncure(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Re: Add minor version to v3 protocol to allowchanges without breaking backwards compatibility
Date: 2012-01-20 02:45:05
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Thu, Jan 19, 2012 at 02:00:20PM -0500, Robert Haas wrote:
> On Thu, Jan 19, 2012 at 10:37 AM, Noah Misch <noah(at)leadboat(dot)com> wrote:
> > I agree with Merlin; the frontend/backend protocol is logically distinct from
> > the binary send/recv formats of data types. ?For one key point, the latter is
> > not exclusively core-defined; third-party extensions change their send/recv
> > formats on a different schedule. ?They can add myext.binary_format_version
> > GUCs of their own to cope in a similar way.
> I agree.  It occurs to me that we recently changed the default *text*
> output format for bytea for reasons not dissimilar to those
> contemplated here.  Presumably, that's a much more disruptive change,
> and yet we've had minimal complaints because anyone who gets bitten
> can easily set bytea_output='escape' and the problem goes away.  The
> same thing seems like it would work here, only the number of people
> needing to change the parameter will probably be even smaller, because
> fewer people use binary than text.
> Having said that, if we're to follow the precedent set by
> bytea_format, maybe we ought to just add
> binary_array_format={huge,ittybitty} and be done with it, rather than
> inventing a minor protocol version GUC for something that isn't really
> a protocol version change at all.  We could introduce a
> differently-named general mechanism, but I guess I'm not seeing the
> point of that either.  Just because someone has a
> backward-compatibility issue with one change of this type doesn't mean
> they have a similar issue with all of them.  So I think adding a
> special-purpose GUC is more logical and more parallel to what we've
> done in the past, and it doesn't saddle us with having to be certain
> that we've designed the mechanism generally enough to handle all the
> cases that may come later.

That makes sense.  An attraction of a single binary format version was avoiding
the "Is this worth a GUC?" conversation for each change.  However, adding a GUC
should be no more notable than bumping a binary format version.

In response to


pgsql-hackers by date

Next:From: Robert HaasDate: 2012-01-20 03:00:15
Subject: Re: Command Triggers
Previous:From: Robert HaasDate: 2012-01-20 02:42:52
Subject: Re: Vacuum rate limit in KBps

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group