You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
pubenumError{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?)
The text was updated successfully, but these errors were encountered:
I'm working on a type that effectively wraps
Client
. For the most part we're just returning underlyingtokio_postgres
errors, so the wrapper's methods all returnResult<_, 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 atokio_postgres::Error
value from it to return to the user. I'd love to have outside access to theError::to_sql
andError::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: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
Error
s in a downstream crate? (Perhaps hidden behind an appropriately-scary feature flag likediesel
'si-implement-a-third-party-backend-and-opt-into-breaking-changes
?)The text was updated successfully, but these errors were encountered: