The JDBC driver has a similar problem and defers switching to binary format until a statement has been reused 5 times; at which point we create a named prepared statement and incur the overhead of an extra round trip for the DESCRIBE statement. Because the extra round trip generally negates any performance enhancements that receiving the data in binary format may provide, we avoid using binary and receive everything in text format until we are sure the extra trip is worth it.
Connection pools further complicate the issue: We can't use named statements with connection pools since there is no binding of the connection to the client. As such in the JDBC driver we recommend turning off the ability to create a named statement and thus binary formats.
As a proof of concept I provide the attached patch which implements the ability to specify which oids will be returned in binary format per session.
IE set format_binary='20,21,25' for instance.
After which the specified oids will be output in binary format if there is no describe statement or even using simpleQuery.
Both the JDBC driver and the go driver can exploit this change with no changes. I haven't confirmed if other drivers would work without changes.
