Pgx: Error codes enum for postgres

Created on 29 Oct 2018  Â·  4Comments  Â·  Source: jackc/pgx

How about having an enum with most useful error codes?

For example:

const (
    // https://www.postgresql.org/docs/10/static/errcodes-appendix.html
    UniqueViolation = "23505"
)

We probably should put it in a separate PostgreSQL specific package, becuase pgx may be used for other databases using postgres wire protocol, and those may have different codes.
So the proposed import path is: github.com/jackc/pgx/errcodes/pgerr
Maybe something more specific is better: github.com/jackc/pgx/errcodes/pg10err

Most helpful comment

All 4 comments

That seems reasonable. And it definitely makes sense to be it's own package. Not sure if splitting by PG version is necessary though. It would really surprise me if PG ever changed the meaning of an existing code.

On a related note, maybe this could be combined with #474. What if instead of a helper method to extract the error code, then presumably further checks on that, the helper method was specific to each error. e.g.

IsUniqueViolation(err) # => true or false 

Haven't thought through that idea, but it might be interesting. It would also keep the error helpers in a different package.

This works too, however with this approach we expose more information. Maybe it's not a good a thing though, and more abstracted IsUniqueViolation might be better that directly exposing codes, like for a hypothetical case where different versions of postgres have different error codes for the same error, and we can abstract those differences away in the IsErrorA-kind of function, that does the right thing regardless of version.
Some more research needed to establish the patterns and methodology around postgres errors. In practie, the above example may never occur, and then it's probably better to just expose raw error codes and let users work with them as values - then it can cover even more usecases than just error kind detection (i.e. error injection).

My original use case is for error detection though, so either way works for me.

Also, a package with just error code constants could be shared across multiple (postgres) database drivers - it doesn't seems to be driver specific.

I think you're right. A package with just the constants is better.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

bernhardreiter picture bernhardreiter  Â·  7Comments

Nokel81 picture Nokel81  Â·  6Comments

danclive picture danclive  Â·  6Comments

kokizzu picture kokizzu  Â·  6Comments

badoet picture badoet  Â·  10Comments