.. if binary_parameters is set. This should mean that both for a direct Query and a Prepare + Query the parameters get the same treatment. Though there's probably not much to gain in the latter case, it's better for consistency.
If set, all parameters of type byte will be sent over as binary data, which allows the driver to avoid the second round-trip to the server when not using a prepared statement proper. This also allows pgbouncer to be used with parameterized queries, which is impossible if binary_parameters has not been enabled. This patch is still missing documentation, but the code has been sitting on my hard drive for long enough. I'll commit the docs in a followup commit. Marko Tiikkaja, with some help from Chris Gilling
This results in a result-less statement's execution requiring us to send two fewer bytes over.
When preparing a statement for repeated execution (as opposed to just parameterizing a single query using the unnamed statement) we get to know the types of the resulting columns before we have to decide which ones to receive in binary and which ones in text. We can use that to our advantage to transparently avoid unnecessary binary -> text -> binary conversions. This has been shown in some cases to provide massive performance benefits, with little to no penalty even in the pathological case. But just to err on the safe side, an option for disabling this feature is provided, disable_prepared_binary_result. It is not documented in the user-facing documentation since its use is expected to be practically nonexistent. In the current state of affairs, only bytea and int8/int4/int2 values are requested in binary from the server. Floats and time-related types are probably the next types to get the same treatment. Chris Bandy and Marko Tiikkaja
ErrBadConns here are completely useless, since there's no database/sql to talk to.
While io.EOF is not the worst choice here, it can be a bit misleading. Fix by providing the accurate error (which should always be set at this point).
…ueued Because the two goroutines acquire the two exclusive locks in different orders, they would deadlock with each other for no reason. Fix by swapping the order of acquisition in acquireSenderLock. If l.err is set nobody should be holding senderLock for a long time anyway, so undesired practical effects of this change should be very minimal.
Spotted some room for improvement while working on 9c01d39.
It looks like looking up "localhost" can sometimes take more than four seconds in Travis, which makes tests with connection timeouts fail sporadically. Try and fix that by avoiding the lookup by using the IP instead.
Previously if sslmode was not explicitly disabled, trying to connect over a UNIX domain socket would result in a "pq: SSL is not enabled on the server" error. This is both silly and incompatible with libpq. Fix by setting "sslmode" to "disable" automatically whenever a connection is made over a UNIX socket.
The problem should be fixed upstream after commit ebe3d693d472f69c. This reverts commit f7ea31d.
The previous coding would output invalid timestamp formats such as "0001-02-03T04:05:06-07:30 BC:09". TruongSinh Tran-Nguyen, with small changes by Eric Urban and myself.