Please export your `error` types (those that can surface to our code) so we can type-check them if so desired

[metaleap]

At least connectError in https://github.com/jackc/pgx/blob/master/pgconn/errors.go — right now, all I can do to prevent users seeing some failed to connect to 'host=%s user=%s database=%s': %s (eg. on overload such as I like to provoke in my test environments) or similar is to give a bland "database problem" or "internal error" on un-matchable (eg. via the very handy SafeToRetry / Timeout helpers) errors .

In this example, if I could without string-pattern-matching detect the ConnectError (vs. others that might also arise from my random current QueryContext/ExecContext call), it could be phrased "briefly down for maintenance" or "it's too popular, we'll be scaling up shortly" etc (since the error can well mean pg's "sorry, too many clients already" rather than true host unreachability). But not if unclear if it's that kind of error.

[jackc]

I think it is a good idea to be able to distinguish connection errors from other errors.

But I'm not sure what is the best approach in this case. Making connectError public would be the simplest for this request, but there are a few other private error types that would be candidates for making public as well. But exposing returned error types is adding to the public interface of the package in a way that can be difficult to do properly -- and once it's public it can't be changed.

In this example, if I could without string-pattern-matching detect the ConnectError (vs. others that might also arise from my random current QueryContext/ExecContext call), it could be phrased "briefly down for maintenance" or "it's too popular, we'll be scaling up shortly" etc (since the error can well mean pg's "sorry, too many clients already" rather than true host unreachability). But not if unclear if it's that kind of error.

This is an example of how it can be tricky to structure these errors. Too many clients could both be a ConnectError and a PgError with error code 53300.

[rrb3942]

I am also running into this. I want to detect if the error from a an insert is a connection related error, or another issue. String matching for 'failed to connect' feels error prone.

This is an example of how it can be tricky to structure these errors. Too many clients could both be a ConnectError and a PgError with error code 53300.

I think that error wrapping gives us a solution for this.

It should always be a ConnectError. From the perspective of caller it may not matter why there is no connection, just that one isn't available. However if we received an error from the PostgreSQL server we can wrap the PgError with the ConnectError to provide more detail and context to the caller.

The caller can then use the errors.Is() and errors.As() functions to examine them for more detail if needed.

Something like:

...
if errors.Is(err, pgconn.ConnectError) {
    var pgErr *pgconn.PgError
    if errors.As(err, &pgErr) {
        //Do something with the PgError
    } else {
       //Generic Connection Error
   }
}
...

[jackc]

ConnectError and ParseConfigError are now public.