Add PgBindIter for encoding and use it as the implementation encoding &[T]

[tylerhawkes]

Partial fix for postgres of #294

I've been using this implementation in several different projects and thought that I would see if it can be accepted upstream. I don't care about the name, but it is only useful when calling .bind(PgBindIter(iter...)), so that's what I've been calling it.

I use this for writing inserts using unnest in postgres and it can easily hit 100k rows/sec on any hardware I've run it on (my mac, ec2, gcp, etc.)

The only overhead this implementation has over the current one for &[T] is the count += 1 in the encoding loop. Hopefully this gets optimized out for slices due to the check in the calling function before delegating the call.

The existing tests for &[T] should cover testing this since it is now the implementation.

I have used a peeking iterator for the first stuff in the past, but that probably has some iteration overhead that is larger than just handling the first item separately.

[paolobarbolini]

Drive-by review: I think this is a good idea. I've left a couple of mostly nitpicks.

[tylerhawkes]

I added a few lines of documentation about why this is useful and how to best use it in postgres with the unnest operator. I also added a test that ensures it works as expected and is usable for owned and borrowed types returned in the iterator.

[tylerhawkes]

Is there anything else I need to do to get this merged?

[tylerhawkes]

I thought about it more and using an extension trait feels a lot nicer of an api to use and it lets us hide some implementation details that aren't important.

Instead of bind_iter as the fn name, maybe into_bind would work better or some other name. This feels nicer to write at the very least.

[abonander]

The plan I had for this was to use Cell<Option<I>> since the Clone bound could theoretically be hard to satisfy for some iterators.

Using Cell would make it !Sync and only able to used once, but those seem like pretty reasonable tradeoffs. I don't expect anyone to need to share this across threads or or need to bind the same iterator more than once (they could just use the same placeholder number to refer to the existing binding or create a new iterator).

It seems like maybe we should split Encode into two traits: one that encodes by-value and one by-reference, then a blanket impl of the former over the latter. The by-reference trait would be the one that most types would implement, but the by-value trait would be the one that all the APIs actually accept.

[tylerhawkes]

Ok, I can make the change. I don't think it will affect the send-ness of the execution future so that should be fine.

I agree with splitting up the Encode trait. It would make this simpler.

[tylerhawkes]

@abonander I've made the change to Cell<Option<I>>