> sometimes we need access to specific data attached to errors (e.g SQLSTATE). Dave's post and my entire comment directly address this: Add a `SQLCode() int` m

> sometimes we need access to specific data attached to errors (e.g SQLSTATE). Dave's post and my entire comment directly address this: Add a `SQLCode() int` method to the custom error, return `error` type and users can assert `codeErr, ok := err.(interface{SQLCode() int}); code := codeErr.SQLCode();` somewhere up the stack to get it. But yes, the standard library's use of sentinel errors is unfortunate and can't be fixed.