> It's great that Harold looked into postgres early, since it has
> almost-but-not-quite-numeric error codes. If the world were a simpler
> place, it would be nice to have a `foreign-error:number` procedure that
> returns an integer or #f. But if we used `foreign-error:symbol` for
> almost-numeric codes like '|28P01|, where would we stash the
> definitely-not-numeric identifiers like 'invalid_password?
>
> A practical solution is to have `foreign-error:code` which can return
> either a number or a symbol or #f, as above. Would this be good enough?

Perusing <https://www.postgresql.org/docs/9.4/errcodes-appendix.html>,
it says that Postgres uses so-called "SQLSTATE" codes for its errors.
That explains why they are all 5 characters long and contain letters as
well as numbers. SQLSTATE comes from ANSI SQL and ODBC.

Instead of:

(foreign-error:error-set ferr) -> 'errno
(foreign-error:symbol ferr) -> 'ENOENT
(foreign-error:code ferr) -> 2

(foreign-error:error-set ferr) -> 'postgresql
(foreign-error:symbol ferr) -> 'invalid_password
(foreign-error:code ferr) -> '|28P01|

should we simply have:

(foreign-error:error-set ferr) -> 'errno
(foreign-error:symbol ferr) -> 'ENOENT
(foreign-error:number ferr) -> 2                  ; code => number

(foreign-error:error-set ferr) -> 'postgresql
(foreign-error:symbol ferr) -> 'invalid_password
(foreign-error:number ferr) -> #f                 ; code => number, #f
result
(foreign-error:data ferr 'sqlstate) -> '|28P01|   ; from custom data alist