Use Error Type instead of fmt.Errorf

[oxzi]

When working with errors returned by pq, lots of those are being generated via fmt.Errorf. This makes it hard to distinguish between different types of errors later in your own code, falling back to doing string prefix checks. So I would like to ask you to provide a separate error type which can be checked downstream.

Thanks a lot for providing this library!

[arp242]

Which error specifically do you want a type for? For some errors it's fine to just use errors.New(), and for many it already pq.Error and some other error types.

[oxzi]

Thanks for coming back to this issue.

Please take a look at this example:
https://github.com/Icinga/icinga-go-library/blob/ab3523b5622f9866a5e164244d421e4365a6969b/retry/retry.go#L184-L194

Here, we had to distinguish between certain errors. There is already the pq.Error type, but not all errors created from this library are using it. Some are created by fmt.Errorf without wrapping pg.Error, but being prefixed by "pq: " as a string.

[arp242]

Which errors do you want to retry? Many errors should probably not be retried.

[arp242]

Via Icinga/icinga-go-library#59 I found Icinga/icingadb#620, where it turns out the message you want to intercept is:

pq: unexpected message 'E'; expected ReadyForQuery

So the bug (in pq) is that 'E' (error) is not handled here. That seems to be #478, which was fixed via #1220.

The mysql driver seem to work the same as pq by the way: it only returns MySQLError for errors returned from the MySQL server. For other errors – including "this protocol seems wrong" type errors like this one – it uses errors.New, either "inline" or as a sentinel error. So that's the same as pq.

It doesn't strike me as too useful to create a new error type for these, because normally these should never happen unless they're bugs in pq, or maybe on the PostgreSQL server side perhaps.

So anyway, with #1220 this seems fixed?