Expose SqliteError::new

[ColonelThirtyTwo]

trafficstars

Is your feature request related to a problem? Please describe. SqliteError has a new function that takes a C handle and generates an error using sqlite3_extended_errcode and sqlite3_errmsg, but it's crate-private. This function would be convenient for anyone working with the C API, for example in SqlitePoolOptions::after_connect to register a custom SQLite function, so that they don't have to write sqlx::Error-compatible error handle themselves.

Describe the solution you'd like Change SqliteError::new to pub and add unsafe to it (it technically should be unsafe even if crate-private since it requires the passed in handle to be valid).

Describe alternatives you've considered Writing my own boilerplate to get the error code and message myself. But it's boilerplate.

Additional context N/A

[abonander]

I agree with adding unsafe, but instead of exposing a constructor for SqliteError, why not add last_error(&mut self) -> Option<SqliteError> to LockedSqliteHandle?

[ColonelThirtyTwo]

LockedSqliteHandle::last_error could work as well. Only reason I can think of for SqliteError::new instead would be if you had a sqlite3_handle but not the LockedSqliteHandle that it came from, and I'm not sure if that's an issue.

[abonander]

Only reason I can think of for SqliteError::new instead would be if you had a sqlite3_handle but not the LockedSqliteHandle that it came from, and I'm not sure if that's an issue.

I mean, if you think there's a real use for it, but my gut says "YAGNI".

Would you be interested in opening a PR?