add `Deref` to `Client` for `Transaction`

[vemoo]

I think that this can be added:

impl<'a> std::ops::Deref for Transaction<'a> {
    type Target = Client;

    fn deref(&self) -> &Self::Target {
        self.client
    }
}

which would make working with transactions easier and make GenericClient unnecessary.

That's how rustqlite does it.

Should I create a PR? or is there something that I'm missing?

[sfackler]

Nested transactions would not be handled properly.

[vemoo]

I see, that would mean that GenericClient is still needed, but since in order to create a transaction you need &mut self, the Deref impl shouldn't be problematic.

[vemoo]

Maybe if savepoints are stored in the Client as a Vec and Transaction just has an index, DerefMut can work for nested transactions.

[vemoo]

Maybe if savepoints are stored in the Client as a Vec and Transaction just has an index, DerefMut can work for nested transactions.

After trying it I've found out that TransactionBuilder wouldn't work properly.

But adding Deref only works.

[bikeshedder]

Actually I do have a branch in my repository that implements Deref and DerefMut for Transaction without breaking transaction nesting.

As far as I can tell the only method exclusive to Client is build_transaction. If it is a problem that this method is also available for Transaction it could be changed so that TransactionBuilder::start returns an Err.

https://github.com/bikeshedder/rust-postgres/tree/feature/transaction-deref

@sfackler Is there anything wrong with this attempt?

[vemoo]

The problem is that you shouldn't be able to call build_transaction if there's already an active transaction. It can be changed to return a Result, but something that was a compile error before will be a runtime error now.

But maybe it's worth it for the ergonomic improvement, and also GenericClient won't be needed anymore.

[sfackler]

This seems like an abuse of Deref to me. I would be more okay with an explicit method to retrieve the Client from a Transaction.

[vemoo]

Would it make sense to add a client method to GenericClient?

My reasoning is that methods that don't need to create transactions can take &Client and avoid having to deal with generics or Box<GenericClient> and the overhead of async_trait boxed futures. This way a method that takes &Client can be called when you have a impl GenericClient.