On Mon, Jan 23, 2012 at 4:12 PM, A.M. <age...@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 format option? That way, an updated > text version could also assume a new int16 format identifier. The client > would simply pass its preferred format. This could also allow for multiple > in-flight formats; for example, if a client anticipates a large in-bound > bytea column, it could specify format X which indicates the server should use > gzip the result before 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers