On Mon, Jan 23, 2012 at 4:12 PM, A.M. <agentm@themactionfaction.com> wrote:
> On Jan 23, 2012, at 4:45 PM, Merlin Moncure wrote:
>> Prefer the version. But why send this over and over with each bind?
>> Wouldn't you negotiate that when connecting? Most likely, optionally,
>> doing as much as you can from the server version? Personally I'm not
>> really enthusiastic about a solution that adds a non-avoidable penalty
>> to all queries.
>
> In terms of backwards compatibility (to support the widest range of clients), wouldn't it make sense to freeze each
formatoption? That way, an updated text version could also assume a new int16 format identifier. The client would
simplypass its preferred format. This could also allow for multiple in-flight formats; for example, if a client
anticipatesa large in-bound bytea column, it could specify format X which indicates the server should use gzip the
resultbefore sending. That same format may not be preferable on a different request.
hm. well, I'd say that you're much better off if you can hold to the
principle that newer versions of the format are always better and
should both be used if the application and the server agree. Using
your example, since you can already do something like:
select zlib_compress(byteacol) from foo;
I'm not sure that you're getting anything with that user facing
complexity. The only realistic case I can see for explicit control of
wire formats chosen is to defend your application from format changes
in the server when upgrading the server and/or libpq. This isn't a
"let's get better compression problem", this is "I upgraded my
database and my application broke" problem.
Fixing this problem in non documentation fashion is going to require a
full protocol change, period. It's the only way we can safely get all
the various players (libpq, jdbc, etc) on the same page without
breaking/recompiling millions of lines of old code that is currently
in production. The new protocol should *require* at minimum the
application, not libpq, to explicitly send the version of the database
it was coded against. That's just not getting sent now, and without
that information there's no realistic way to prevent application
breakage -- depending on libpq versions is useless since it can be
upgraded and there's always jdbc to deal with.
merlin
