On Thu, Jan 19, 2012 at 02:00:20PM -0500, Robert Haas wrote:
> On Thu, Jan 19, 2012 at 10:37 AM, Noah Misch <n...@leadboat.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.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
