The existing methods which take slices of parameters work well when
directly passing a temporary slice (e.g. `c.query(s, &[&15, &"hi"])`,
but becomes limiting in other contexts like when programmatically
building up a query. We now offer methods which take iterators, which
are significantly more flexible for these kinds of use cases.
Because of the weird object safety of `ToSql`, we can't be generic over
`Iterator<Item = impl ToSql>`, but instead have to specifically work
with `Iterator<Item = &dyn ToSql>`. This may require a `.map()` or two
but should still work fine.
Closes#265
copy_in data was previously copied ~3 times - once into the copy_in
buffer, once more to frame it into a CopyData frame, and once to write
that into the stream.
Our Codec is now a bit more interesting. Rather than just writing out
pre-encoded data, we can also send along unencoded CopyData so they can
be framed directly into the stream output buffer. In the future we can
extend this to e.g. avoid allocating for simple commands like Sync.
This also allows us to directly pass large copy_in input directly
through without rebuffering it.
Multi-host support means we can't simply take the old approach - we need
to know which of the hosts we actually connected to. It's also nice to
move this from the connection to the client since that's what you'd
normally have access to.
* `Connection` is now parameterized over the stream type, which can be
any `AsyncRead + AsyncWrite`.
* The `TlsMode` enum is now a trait, and `NoTls`, `PreferTls`, and
`RequireTls` are types implementing that trait.
* The `TlsConnect` trait no longer involves trait objects, and returns
channel binding info alongside the stream type rather than requiring
the stream to implement an additional trait.
* The `connect` free function and `ConnectParams` type is gone in favor
of a `Builder` type. It takes a pre-connected stream rather than
automatically opening a TCP or Unix socket connection.
Notably, we no longer have any dependency on the Tokio runtime. We do
use the `tokio-codec` and `tokio-io` crates, but those don't actually
depend on mio/tokio-reactor/etc. This means we can work with other
futures-based networking stacks.
We will almost certainly add back a convenience API that offers
something akin to the old logic to open a TCP/Unix connection
automatically but that will be worked out in a follow up PR.
The TransactionBuilder is useful when trying to create a Transaction
around a future which takes ownership of the client. See doc comment
for more details.
