provide typed error codes

[ibotty]

it would be great, if you could add a function to decode the error codes postgres returns. (SqlError's sqlState in postgresql-simple).

it might also be nice to categorize them (i.e. Class 03 — SQL Statement Not Yet Complete).

to maintain api compatibility i suggest the following functions.

insufficientPrivilege :: ByteString
insufficientPrivilege = B.pack "42501"
-- and the other error codes
sqlStateClass :: ByteString -> SqlStateClass 

if api compatibility is not strictly necessary, i propose the (imo cleaner) approach to at least newtype-wrap sqlState or use a real enumerated type.

i would prepare a patch with either approach, if you like.

http://www.postgresql.org/docs/current/static/errcodes-appendix.html

[ibotty]

what if any approach do you like? i'd like to have a go at adding proper handling of failed constraints to postgresql-simple.

[lpsmith]

Ahh, well you did post this under postgresql-libpq, and I think this suggestion is out of scope for postgresql-libpq.

It's a fine thing to do for postgresql-simple, however. I think I'd be inclined to prefer the latter approach, to preserve SqlError as-is. The Simple.Errors module already has some functions to dissect SqlError values, if you'd like to work on that, that would be fine.

[ibotty]

i guess i see your point, but i thought the table on all the sqlstates should be right next to libpq. i'll add the table to postgresql-simple then.

[lpsmith]

Well, postgresql-libpq is meant to be a pretty lean abstraction over libpq; without adding much itself. So if libpq offered such a table, then I wouldn't hesistate to put it.

How well it lives up to this up to this ideal isn't entirely clear to me. Certainly, code-size wise it's not looking great, but then neither does anything compiled by GHC, really. =)

[ibotty]

there is a header file in libpq that lists all sqlstates, but it's easier to generate from a text file in the postgresql sources (which in turn is used for generating the header file and the online documentation).

Having said that, i don't care where it ends up. I only like to avoid hardcoding magic numbers in app code.

[lpsmith]

Hmm, well if all you are looking for is a table, then... I dunno. It would inflate the size of the binary a bit, but then again the binary for postgresql-libpq is considerably larger than libpq itself. (eep!) So I'm not too worried on that count, though I'd be interested in finding out how big it turns out to be.