This will make imports simpler

It's possible to use client.prepare to get a Statement object and execute / query it later. Since Statements need to be used on the same connection that created them, l337 would require some ability to bundle state along with each connection for that to work.

I wanted to go full async with the application I'm currently building and tried both bb8 and l337 with tokio-postgres just to find that both performed worse than r2d2 with postgres:

https://bitbucket.org/bikeshedder/actix_web_async_postgres/src/master/

Am I doing anything wrong or is this maybe an issue with tokio-postgres?

The postgres adapter crate name should be l337-postgres, and we should move it into its own repo before publishing. Or, at the very least, we should move it into an appropriate sub-folder (l337-postgres).

Use the dyn keywords for trait objects

src/conn.rs:51, src/inner.rs:82, src/manage_connection.rs:42, src/manage_connection.rs:51, src/lib.rs:128, src/lib.rs:210:21.

Add ci to project

I'm using l337 and l337-postgres in my current project using the following lines in my Cargo.toml:

[dependencies.l337]
git = "https://github.com/OneSignal/L3-37"
rev = "6d96fefa75c748d4ac3618ab2bd9523d589b6cd2"

[dependencies.l337-postgres]
git = "https://github.com/OneSignal/L3-37"
rev = "6d96fefa75c748d4ac3618ab2bd9523d589b6cd2"

Are there any plans on releasing l337 and l337-postgres to crates.io in the near future?

It appears that the future returned from Pool::connection in the futures-03 branch borrows &self, whereas in the master branch it does not. This means that in order to spawn the future onto some executor where it needs to be 'static, the pool must be wrapped in an Arc (as a workaround). This is different to on the master branch where this extra step was not required. I believe that this is because async fn returns a future which borrows all of the arguments to the function, where as the version manually returning a future did not. This could perhaps be fixed with inline async blocks. I'm just putting this issue here to let you know about the change.

The race condition we fixed happens when accessing both of these. The Mutex should wrap both of them to provide type safety on their access.