Expose error code for PG backend

[jrandolf]

This allows for robust handling of PG errors that are not already enumerated.

[weiznich]

Thanks for opening this PR. Could you provide some more details about which SQL Error codes you want to handle outside of diesel and why that's required.

Additionally: I fear we cannot merge the PR as it is as it contains a breaking change (adding a new required method to an public trait).

Finally: There should be at least one test for this.

[jrandolf]

I'd like to handle exclusion errors, but possibly others if they come up. I'd rather not file a PR for each case though, so it makes more sense IMO to just expose the code. After all, sql state is somewhat standardized AFAIU. Perhaps not the codes themselves, but the concept of a code itself.

I will add a test.

Would you like me to just add a default implementation to code?

[Ten0]

I'd like to handle exclusion errors, but possibly others if they come up. I'd rather not file a PR for each case though, so it makes more sense IMO to just expose the code

IMO adding those to DatabaseErrorKind will result in a more readable and less error-prone code when matching on those errors, and in addition it wouldn't be a breaking change, as documented on DatabaseErrorKind (which is also marked as #[non_exhaustive]).
Adding the 2 or 3 "Integrity Constraint Violations" that are still missing there would seem reasonable, and I would tend to imagine that that represents most of the "other cases that one may want to catch later on".

I'm not opposed to adding the method currently suggested by this PR but the above feels like a reasonable first step given the compromise that there is otherwise between backwards compatibility (previously mentioned breaking change) and correctness (any existing implementation of this trait is unlikely to be as correct as it should be if we add a default impl for this method).

[jrandolf]

@Ten0 Alright, I've just added the remaining constraints to the enum. Do you folks want test for these errors or is this sufficient?

[Ten0]

LGTM apart from this