sfackler / rust-postgres

Native PostgreSQL driver for the Rust programming language
Apache License 2.0
3.44k stars 436 forks source link

Conversion from WrongType to Error? #1011

Open couchand opened 1 year ago

couchand commented 1 year ago

I'm working on a type that effectively wraps Client. For the most part we're just returning underlying tokio_postgres errors, so the wrapper's methods all return Result<_, tokio_postgres::Error>. This has been working very well for basic usage, but I'm running into situations where it breaks down. Namely, we want to do additional verification ahead of time.

I am in a situation where I have a postgres_types::WrongType enum value and a parameter or column index, and I'd really like to be able to produce a tokio_postgres::Error value from it to return to the user. I'd love to have outside access to the Error::to_sql and Error::from_sql methods, since they look to do exactly what I want and those errors already represent my error conditions.

I understand you're trying to minimize the API surface of the Error type. However, I'd really like to not have to introduce my own error enum here, since it would basically be replicating what tokio_postgres::Error already has:

pub enum Error {
    Upstream(tokio_postgres::Error),
    ToSql(usize, Box<dyn error::Error + Sync + Send>),
    FromSql(usize, Box<dyn error::Error + Sync + Send>),
    // potentially other variants representing other errors I can't construct
}

// plus a whole lot of boilerplate to make it useful for users

I'd much rather continue using tokio_postgres::Error, since it already has variants representing the error cases I'm working with, and if the user doesn't need to think about an additional error type the API would be much more approachable.

Would you be open to some way of producing Errors in a downstream crate? (Perhaps hidden behind an appropriately-scary feature flag like diesel's i-implement-a-third-party-backend-and-opt-into-breaking-changes?)